Re: Python Worst Practices
On Fri, Feb 27, 2015 at 9:42 PM, Dan Sommers wrote: > I don't think I've ever used the builtin function id in a program. > Ever. Not even once. Honestly, what is a valid use case? If you have a dict that you want to key on object identity rather than equality, then you can use object ids as the keys. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
Ethan Furman : > Sure, for the ones I use as built-ins. But I went through the color > file for vim and took out the built-ins I use regularly as variables > -- and 'id' was the first one to go. Ah, yes. The id is with us from the beginning. The self seeks to gratify the whims of the id while at least placating the demands of super. But I think stamping out the id altogether is bound to fail and risk the long-term soundness of the implementation. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Sat, Feb 28, 2015 at 6:50 PM, Dan Sommers wrote: > Now if only emacs were clever enough *not* to colorize "id" when it's > one of my names and not the builtin... ;-) I think (part of) the point of the colorization is to make it obvious that you've shadowed a builtin. If you use << str = 'spam' >> in your code, the str should be highlighted. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Sat, Feb 28, 2015 at 7:48 PM, Ian Kelly wrote: > On Fri, Feb 27, 2015 at 9:42 PM, Dan Sommers wrote: >> I don't think I've ever used the builtin function id in a program. >> Ever. Not even once. Honestly, what is a valid use case? > > If you have a dict that you want to key on object identity rather than > equality, then you can use object ids as the keys. And not forget to hang onto references to all those objects, else their ids will be meaningless. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 25/02/2015 20:58, Michiel Overtoom wrote: On Feb 25, 2015, at 21:45, Mark Lawrence wrote: http://www.slideshare.net/pydanny/python-worst-practices I like the way it advises against preserving pixels by removing vowels from identifiers. Then it gives the best practice example of using "color" instead of "clr" or "c"! (Over here it's spelled "colour"...) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 28/02/2015 01:09, Steven D'Aprano wrote:
Likewise:
int = 23
n = int("42")
Isn't it obvious that the second use of int has to be the built-in function?
I wish that the computer would understand from context which one I mean.
(People here would like PL/I then which apparently has *no* reserved
words, so you can write: "if if=then then ...")
Other newbie stylistic mistakes which can increase the chance of shadowing
errors include:
* Too many overly generic variable names like "int" and "str".
One thing I find annoying when looking at tutorial examples of an
unfamiliar language is when they use identifier names such as
"function", "array", "integer", "var" and so on, names which could
conceivably be reserved words.
Because it's not clear if these *are* keywords that form part of the
syntax, or built-ins, or actual made-up user identifiers.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
BartC : > (Over here it's spelled "colour"...) The language of science and technology is American English. Learn it like everybody else has to. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: requesting you all to please guide me , which tutorials is best to learn redis database
On Thu, 26 Feb 2015 11:14:50 -0800, Jai wrote: > i want to learn redis database and its use via python , please > guide me which tutorials i should be study, so that i can learn it > in good way Using databases via python often involves working with dictionaries or lists, lists of dictionaries, lists of lists etc. Before you start trying to work with a database and python together, you should have a good grasp of the core python data structures, built in functions, statements, io, statements, flow control etc. You should also have a good grasp of the language (presumably an sql variant) used by the database, and a very good understanding of how string formatting works in python, as you'll be using python to build command strings to send to the database. Then you may be ready to start gluing the two together. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Sat, Feb 28, 2015 at 9:39 PM, BartC wrote: > (People here would like PL/I then which apparently has *no* reserved words, > so you can write: "if if=then then ...") Likewise REXX has no reserved words; also, SQL went part-way there, with the notion of "non-reserved keywords". For example, "ORDER" and "BY" are reserved keywords, so they are unavailable as table/column names, but "NULLS" is non-reserved. You could use it, if you wanted to, but it's a syntactic element in some contexts. You can say "ORDER BY some_column NULLS FIRST" or "NULLS LAST" to affect the ordering; you can even say "ORDER BY NULLS NULLS FIRST", which will sort by a column named NULLS, in ascending order, but counting NULL as lower than everything (instead of higher than everything). Given the style of SQL, it'd be insanely restrictive if it had to have everything be either a keyword or nothing, so this is a good half-way-house. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 27/02/2015 21:40, Chris Angelico wrote: On Sat, Feb 28, 2015 at 8:37 AM, Dave Angel wrote: Right. In C and C++, instead of being the first slide, it'd be the first 3 or 4. Between header file conflicts (especially good because the stdlib itself has many multiply-defined symbols, duplicate header files, and contradictory include path patterns) Yeah, Python has some issues with sys.path and how your local module can unexpectedly shadow a stdlib one, but at least the stdlib itself doesn't have any conflicts. I should not ever have to do this dance: #include #undef SOME_SYMBOL #include But sadly, I do. ChrisA As you typed the above up I wonder how many developers around the world were battling with the fun and games caused, particularly when writing cross platform code? It also makes me wonder what idiot decided to use C as the language for the first Python implementation? Or was it written in something else and then ported? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 28/02/2015 10:56, Marko Rauhamaa wrote: BartC : (Over here it's spelled "colour"...) The language of science and technology is American English. Learn it like everybody else has to. Marko People from Angleland use any English apart from our own, never. Next thing you'll be telling us to use that new fangled UTC nonsense instead of the clearly correct GMT. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Sun, Mar 1, 2015 at 2:33 AM, Mark Lawrence wrote: > > It also makes me wonder what idiot decided to use C as the language for the > first Python implementation? Or was it written in something else and then > ported? Guido, probably. And what other language would you suggest? What other language has comparably extensive multi-platform support? Writing a Python implementation in C instantly makes Python available on all sorts of platforms, with direct access to native libraries on all of them. For example, CPython on Windows can make use of a whole bunch of Microsoft's win32 APIs, via the pywin32 extensions; meanwhile, CPython on Linux can use the inotify functions, again via an extension module (pyinotify or python-inotify). Jython doesn't offer that, as far as I know; or rather, Jython offers access to Java classes rather than to C libraries, and there are a lot more of the latter than the former. Of all the languages that offer convenient access to the same sorts of libraries that C code can (generally, those that compile to machine code and use the same kinds of linker information), which would you suggest as being better than C? C may not be perfect, but it's pretty decent at what it does. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
> From : Tim Chase > > A quick google-and-tally for languages > and their corresponding number of keywords: > re-sorted 21 : Lua 31 : Python2.x 33 : Python3.x 33 : C 37 : Pike 40 : Perl 40 : Ruby 50 : Java 54 : Pascal 67 : PHP 77 : C# 86 : C++ -- Stanley C. Kitching Human Being Phoenix, Arizona -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Saturday, February 28, 2015 at 9:34:05 PM UTC+5:30, Cousin Stanley wrote: > > From : Tim Chase > > > > A quick google-and-tally for languages > > and their corresponding number of keywords: > > > > re-sorted > > 21 : Lua > 31 : Python2.x > 33 : Python3.x > 33 : C > 37 : Pike > 40 : Perl > 40 : Ruby > 50 : Java > 54 : Pascal > 67 : PHP > 77 : C# > 86 : C++ Ah so after 20 years of development, python has entered the equivalence class of C -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 28/02/2015 15:46, Chris Angelico wrote: On Sun, Mar 1, 2015 at 2:33 AM, Mark Lawrence wrote: It also makes me wonder what idiot decided to use C as the language for the first Python implementation? Or was it written in something else and then ported? Guido, probably. And what other language would you suggest? What other language has comparably extensive multi-platform support? Writing a Python implementation in C instantly makes Python available on all sorts of platforms, with direct access to native libraries on all of them. For example, CPython on Windows can make use of a whole bunch of Microsoft's win32 APIs, via the pywin32 extensions; meanwhile, CPython on Linux can use the inotify functions, again via an extension module (pyinotify or python-inotify). Jython doesn't offer that, as far as I know; or rather, Jython offers access to Java classes rather than to C libraries, and there are a lot more of the latter than the former. Of all the languages that offer convenient access to the same sorts of libraries that C code can (generally, those that compile to machine code and use the same kinds of linker information), which would you suggest as being better than C? C may not be perfect, but it's pretty decent at what it does. ChrisA I love fishing, just dangle the bait and wait to see what bites :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Sun, Mar 1, 2015 at 3:28 AM, Mark Lawrence wrote: > I love fishing, just dangle the bait and wait to see what bites :) Yeah, you usually catch someone. Sometimes they need to be majorly sleep-deprived at half past three in the morning so they're looking at message bodies and skipping the headers that say who actually said stuff... but you'll catch someone. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 28/02/2015 16:36, Chris Angelico wrote: On Sun, Mar 1, 2015 at 3:28 AM, Mark Lawrence wrote: I love fishing, just dangle the bait and wait to see what bites :) Yeah, you usually catch someone. Sometimes they need to be majorly sleep-deprived at half past three in the morning so they're looking at message bodies and skipping the headers that say who actually said stuff... but you'll catch someone. ChrisA If I had a quid for every time I'd posted when sleep deprived at half past three in the morning, and this on top of Chronic Fatigue Syndrome, then I'd have retired years ago. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 2015-02-28 16:03, Cousin Stanley wrote: From : Tim Chase A quick google-and-tally for languages and their corresponding number of keywords: re-sorted 21 : Lua 31 : Python2.x 33 : Python3.x 33 : C 37 : Pike 40 : Perl 40 : Ruby 50 : Java 54 : Pascal 67 : PHP 77 : C# 86 : C++ Does any language have more than COBOL? That has hundreds! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 28/02/2015 15:33, Mark Lawrence wrote: It also makes me wonder what idiot decided to use C as the language for the first Python implementation? Or was it written in something else and then ported? Python was already slow enough even written in C. With any other implementation language, it would have ground to a halt. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 02/28/2015 09:56 AM, MRAB wrote: > On 2015-02-28 16:03, Cousin Stanley wrote: >> >>> From : Tim Chase >>> >>> A quick google-and-tally for languages >>> and their corresponding number of keywords: >>> >> >>re-sorted >> >> 21 : Lua >> 31 : Python2.x >> 33 : Python3.x >> 33 : C >> 37 : Pike >> 40 : Perl >> 40 : Ruby >> 50 : Java >> 54 : Pascal >> 67 : PHP >> 77 : C# >> 86 : C++ >> > Does any language have more than COBOL? That has hundreds! I think Visual FoxPro should get at least an (dis)honorable mention -- I didn't count, but there are several page-fulls [1]. -- ~Ethan~ [1] https://msdn.microsoft.com/en-us/library/xztfc506%28v=vs.80%29.aspx signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 2015-02-28 17:56, MRAB wrote: > On 2015-02-28 16:03, Cousin Stanley wrote: > > > >> From : Tim Chase > >> > >> A quick google-and-tally for languages > >> and their corresponding number of keywords: > >> > > > >re-sorted > > > > 21 : Lua > > 31 : Python2.x > > 33 : Python3.x > > 33 : C > > 37 : Pike > > 40 : Perl > > 40 : Ruby > > 50 : Java > > 54 : Pascal > > 67 : PHP > > 77 : C# > > 86 : C++ > > > Does any language have more than COBOL? That has hundreds! A quick check using [1] suggests that COBOL has 366, while according to [2], MySQL's flavor of SQL has 825. -tkc [1] http://cobol.404i.com/res.php [2] https://www.drupal.org/node/141051 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 28/02/2015 17:55, BartC wrote: On 28/02/2015 15:33, Mark Lawrence wrote: It also makes me wonder what idiot decided to use C as the language for the first Python implementation? Or was it written in something else and then ported? Python was already slow enough even written in C. With any other implementation language, it would have ground to a halt. I'm disappointed with the catch so far, this is only the second for my keep net. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On 2015-02-28 10:13, Ethan Furman wrote: > On 02/28/2015 09:56 AM, MRAB wrote: > > On 2015-02-28 16:03, Cousin Stanley wrote: > >> > >>> From : Tim Chase > >>> > >>> A quick google-and-tally for languages > >>> and their corresponding number of keywords: > >>> > >> > >>re-sorted > >> > >> 21 : Lua > >> 31 : Python2.x > >> 33 : Python3.x > >> 33 : C > >> 37 : Pike > >> 40 : Perl > >> 40 : Ruby > >> 50 : Java > >> 54 : Pascal > >> 67 : PHP > >> 77 : C# > >> 86 : C++ > >> > > Does any language have more than COBOL? That has hundreds! > > I think Visual FoxPro should get at least an (dis)honorable mention > -- I didn't count, but there are several page-fulls [1]. That list has ~2405 entries, but it's been long enough since I've used VFP (c. 2000) that I've successfully managed to repress the nuances of whether those are actual reserved words, or whether, like Python built-ins, they're more suggestions rather than enforced. -tkc -- https://mail.python.org/mailman/listinfo/python-list
PIL installation fails; registration problem
I am reinstalling everything on my new Windows 7 laptop. I run into a problem when installing PIL 1.1.7, in combination with my Activestate Python 2.7.8. The PIL installer complains that no Python is registered. I did run Joakim Löw's script to register Python. This results in the message "*** You probably have another Python installation!". Adding some code to this script reveals that my Python is registered with the following values (deviating from the values in the script): installkey: C:\Python27\ pythonkey C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk The script proposes for pythonkey: C:\Python27;C:\Python27\Lib\;C:\Python27\DLLs\ Can I change the pythonkey to the value proposed by Joakim Löw's script? -- https://mail.python.org/mailman/listinfo/python-list
suggestions for functional style (singleton pattern?)
Hi, For some scripts, I write in a a more functional way, using a lot of small functions outside of any class. Although it makes the code clearer for specific cases, I have found that it makes debugging and using the repl in general difficult, as as I have to re-initialise every single objects every time. I have now started to use some kind of state pattern to alleviate this, here's a simplistic example: https://github.com/dorfsmay/state_pattern_for_debugging_python/blob/master/dirstats.py Are there better ways to address this? Any suggestion on this style? Thanks. -- http://yves.zioup.com gpg: 4096R/32B0F416 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
Chris Angelico wrote: Likewise REXX has no reserved words; also, SQL went part-way there, with the notion of "non-reserved keywords". Python sometimes has those, too. For example, the "as" in "import as" was non-reserved when it was first introduced, to avoid abruptly breaking code that used it as a name. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
On 02/28/2015 04:12 PM, y...@zioup.com wrote: > For some scripts, I write in a a more functional way, using a lot of small > functions outside of any class. Although it makes the code clearer for > specific cases, I have found that it makes debugging and using the repl in > general difficult, as as I have to re-initialise every single objects every > time. > > I have now started to use some kind of state pattern to alleviate this, here's > a simplistic example: > > https://github.com/dorfsmay/state_pattern_for_debugging_python/blob/master/dirstats.py > > Are there better ways to address this? Any suggestion on this style? You say you are trying to use a singleton pattern, but your code does not appear to implement a singleton. From what I can read of your code, you really should just put all your functions as methods to the DirStat class and call it good. Especially if your module is going to be used in several places potentially at the same time. If what you want is a singleton, then that's what a module is already. Module functions are singleton methods and module attributes maintain state. Just call your module dirstat and interface with it: dirstat.opendir(**vars(args) dirstat.print() In this example, I really don't think the singleton is a good pattern, though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
BartC wrote: > On 28/02/2015 15:33, Mark Lawrence wrote: > >> It also makes me wonder what idiot decided to use C as the language for >> the first Python implementation? Or was it written in something else and >> then ported? > > Python was already slow enough even written in C. Tell that to the IronPython developers. Of course, benchmarks are very variable, depending on what you wish to do, and a few things (like exceptions) are very much slower in IronPython: http://ironpython.codeplex.com/wikipage?title=IP27A1VsCPy27Perf&referringTitle=IronPython%20Performance but overall, I think it's fair to say that IronPython is about 1.8 times the speed of CPython. > With any other implementation language, it would have ground to a halt. That's laughably inaccurate. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Worst Practices
On Sun, Mar 1, 2015 at 1:08 PM, Steven D'Aprano wrote: > but overall, I think it's fair to say that IronPython is about 1.8 times the > speed of CPython. > > >> With any other implementation language, it would have ground to a halt. > > That's laughably inaccurate. I'm sure that Python could have been implemented in FORTRAN without losing performance. Conversely, I'm sure Python could also have been implemented on top of BASIC if someone felt like it, though what the advantages might be I have no idea. But performance is not (or should not be) the primary reason for choosing a language. Imagine if all your Python code ran twice as fast (that's slightly better than the IronPython figure quoted!), but worked only on BSD Unix and Mac OS. Is that something that'll make a fledgling language succeed? Or would universality, even at the cost of performance, lead to a greater userbase and development team, which ultimately would result in far greater improvements in both functionality and performance? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
On Sat, 28 Feb 2015 16:12:54 -0700, y...@zioup.com wrote: >Hi, > >For some scripts, I write in a a more functional way, using a lot of small >functions outside of any class. Although it makes the code clearer for >specific cases, I have found that it makes debugging and using the repl in >general difficult, as as I have to re-initialise every single objects every >time. > >I have now started to use some kind of state pattern to alleviate this, here's >a simplistic example: > >https://github.com/dorfsmay/state_pattern_for_debugging_python/blob/master/dirstats.py > >Are there better ways to address this? Any suggestion on this style? (warning: Didn't bother prove-reading and spell chocking. Sorry...) Problem 1: With the exception of get_all_files(), all your functions do is to call another standard function. This decreases performance unnecessarily and may mislead the users of your API into thinking these functions perform some different type of average or min/max operations. For a single call to your API, the performance issue isn't a problem. But if some user wraps a DirStat instance in a loop, they may suffer an unnecessary hit. Meanwhile, If I see a calculate_average() or a find_smallest() function in your API, I immediately deduce it must be doing something different than a standard average or min/max operation. Otherwise why would the API code bother about something I can easily do myself? And when I go look in your code trying to understand why you are offering me an average function, I'll become dissapointed. Solution: Do not create an interface for standard functions, unless you plan to change how these functions work. Your desire to let your users know that they can calculate an average from your API object will fall in deaf ears because they can realize that from themselves. An API should only expose unique methods or complex operations wrapped in one or two methods. If you are coding a method with a single line and that line starts with return and is followed by a function call, you know you are creating a redundant interface. Problem 2: No one likes long names. And if some user of your API is coding under an 80 character per line limit, they'll hate you for it. Your functions contain redundant terms that only increase the function name size and do not offer any advantage in having a better grasp of what the function does. average() is better than calculate_average(), for instance. Solution: Always be careful with how you name your public interface elements. These will define much of the 'personality' of your API. calculate_average() makes for a tacky API. average() makes for a pretty standard API. Problem 3: Modules are self-contained contextualized units that must contain only code that fits in the namespace the module defines for itself. If this module is called dirstats and is chiefed by a DirStats object that manages a dictionary of files, a public calculate_average() function or a min/max pair of functions simply don't fit within the module context. At the very least they should be moved inside the class so it becomes clear to anyone caring that these functions really only matter in the context of the DirStats object. (But because of problem 1, these functions should not even exist and instead be replaced by direct calls to the statistics module functions inside the DirStats class.) The get_all_files() function is an offender. It should be moved inside the class and probably even be removed entirely. Since it apparently has no other objective than to help the class __init__() method, the function code just just be copied/pasted inside that method. Solution: Do not make a module a house of confusion. Each module should contain only public functions and objects that belong with each other under the module proposed context. Also look carefully at what you are putting outside of a class. You are making it a part of the public interface for that module. The only reason to do so is if it can have some use outside the class definition. Problem 4: You speak of a singleton. But you haven't implemented one. It is not clear from your code if this class should be a singleton. I'm guessing not. Singletons are in fact rare. Well, let me put it another way: Good reasons to code a singleton are rare. A good singleton, for instance could be the Map() object in a strategy game, or the canonical Logging() class in most programs that implement logging. These are really one-time objects that make sense to ever always exist as just one instance. Solution: But, if you ever wish to implement a singleton, the following pattern mostly works and is short and to the point: class Map(): _instance = None def __new__(cls, *args, **kwargs): if Map._instance is None: Map._instance = super(Map, cls).__new__(cls) return Map._instance >>> a = Map() >>> b = Map() >>> a is b True Just remember, for most singletons the truth is th
Re: suggestions for functional style (singleton pattern?)
On 2015-02-28 19:19, Michael Torrie wrote: > You say you are trying to use a singleton pattern, but your code does > not appear to implement a singleton. From what I can read of your code, I call it a singletone because I only every create one object. I am not trying to use a singleton, I'm trying to avoid issues created by the alternative ways of doing this (not having access to the variables in the repl etc...). > you really should just put all your functions as methods to the DirStat > class and call it good. Especially if your module is going to be used > in several places potentially at the same time. There are type of problems where I don't want to bind functions to data. By the way, I have just added some more explanation in the code, trying to clarify the problem. -- http://yves.zioup.com gpg: 4096R/32B0F416 -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
On 2015-02-28 20:45, Mario Figueiredo wrote: > Problem 1: > With the exception of get_all_files(), all your functions do is to > call another standard function. This decreases performance > unnecessarily and may mislead the users of your API into thinking > these functions perform some different type of average or min/max > operations. I tried to create a simple example to make a point, I wouldn't create function wrappers like this. I'll to think of a better example, this was to get the discussion going. > Problem 3: > At the very least they should be moved inside the class so it becomes > clear to anyone caring that these functions really only matter in the > context of the DirStats object. Trying to write in a more functional way, not OO here, the functions could be used by more than one class. I understand OO, use it a lot, but sometimes try to move beyond that. > Problem 4: > You speak of a singleton. But you haven't implemented one. It is not > clear from your code if this class should be a singleton. I'm guessing > not. Singletons are in fact rare. Well, let me put it another way: > Good reasons to code a singleton are rare. Thanks. I hadn't realise "singleton" meant a class built such that it could not be instanciated more than once, I thought it corresponded to a pattern where only one object is ever created from a given class. > But, if you ever wish to implement a singleton, the following pattern > mostly works and is short and to the point: > > class Map(): > _instance = None > > def __new__(cls, *args, **kwargs): > if Map._instance is None: > Map._instance = super(Map, cls).__new__(cls) > return Map._instance > > >>> a = Map() > >>> b = Map() > >>> a is b > True Thanks. > Problem 5: > A pet peeve of mine. If you aren't going to use a variable, make that > explicit in your code by taking advatange of Python wonderful language > features. Good point - thanks. -- http://yves.zioup.com gpg: 4096R/32B0F416 -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
On 02/28/2015 09:29 PM, y...@zioup.com wrote: >> Problem 4: >> You speak of a singleton. But you haven't implemented one. It is not >> clear from your code if this class should be a singleton. I'm guessing >> not. Singletons are in fact rare. Well, let me put it another way: >> Good reasons to code a singleton are rare. > > Thanks. I hadn't realise "singleton" meant a class built such that it could > not be instanciated more than once, I thought it corresponded to a pattern > where only one object is ever created from a given class. Is not "only one object is ever created from a given class" the same as "could not be [instantiated] more than once?" To be clear, singletons are commonly used in Python every time you import a module. A module *is* a singleton pattern, particularly one that maintains state. I use sometimes use this feature for sharing config and other data between other modules (global state when it's required). "import module" essentially does the one-time instantiation if it's a new import; top-level code in the module is run once on first import, where it acts like a constructor. So it functions as a singleton. As near as I can tell there's very little reason to make a class-based singleton in Python, since a module has the same effect and is cleaner. -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
On 02/28/2015 09:11 PM, y...@zioup.com wrote: > On 2015-02-28 19:19, Michael Torrie wrote: >> You say you are trying to use a singleton pattern, but your code does >> not appear to implement a singleton. From what I can read of your code, > > I call it a singletone because I only every create one object. > > I am not trying to use a singleton, I'm trying to avoid issues created by the > alternative ways of doing this (not having access to the variables in the repl > etc...). > > There are type of problems where I don't want to bind functions to data. > > By the way, I have just added some more explanation in the code, > trying to clarify the problem. I suppose it's just a matter of style but I'd just have my utility function return a dict of all the calculated values, rather than store them in a utility class instance. Then you wouldn't need an intermediate object to hold state temporarily. The idea behind functional programming in part is you can chain things together easily should you need to, which your intermediate object cannot do. But I do see kind of the pattern you are trying to employ here; I just don't understand why it's required or what you'd use it for, given that a function could just do all the calculations and return a list or dict of all calculated the values. -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
y...@zioup.com wrote: Thanks. I hadn't realise "singleton" meant a class built such that it could not be instanciated more than once, It doesn't have to be, it could just be a class that you refrain from instantiating more than once. But as Michael Torrie said, it's rare to need to to that in Python. Most of the time you're better off using a module. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: suggestions for functional style (singleton pattern?)
y...@zioup.com writes: > Are there better ways to address this? Any suggestion on this style? I guess I don't completely understand the question. But one way to do a singleton in python is put the initialization code into a separate module. Then the first time you import the module, the code runs, but it doesn't re-run on subsequent imports. -- https://mail.python.org/mailman/listinfo/python-list
