Re: A question of style (finding item in list of tuples)

On Monday, May 21, 2012 9:39:59 AM UTC-4, Jon Clements wrote: > > def experience_text(self): > > return dict(CHOICES).get("self.level", "???") > Haven't used django in a while, but doesn't the model provide a > get_experience_display() method which you could use... Duh, I totally mi

Re: A question of style (finding item in list of tuples)

On Monday, 21 May 2012 13:37:29 UTC+1, Roy Smith wrote: > I've got this code in a django app: > > CHOICES = [ > ('NONE', 'No experience required'), > ('SAIL', 'Sailing experience, new to racing'), > ('RACE', 'General racing experience'), > ('GOOD', 'Experienced

Re: A question of style (finding item in list of tuples)

On 05/21/12 08:10, Steven D'Aprano wrote: > On Mon, 21 May 2012 08:37:29 -0400, Roy Smith wrote: > > [...] >> The above code works, but it occurs to me that I could use the much >> shorter: >> >> def experience_text(self): >> return dict(CHOICES).get("self.level", "???") >> >> So, the

Re: A question of style (finding item in list of tuples)

One suggestion is to construct the dictionary first: CHOICES = dict( NONE = 'No experience required', SAIL = 'Sailing experience, new to racing', RACE = 'General racing experience', GOOD = 'Experienced racer', ROCK = 'Rock star' ) def experience_text(self): try:

Re: A question of style (finding item in list of tuples)

On Mon, 21 May 2012 08:37:29 -0400, Roy Smith wrote: [...] > The above code works, but it occurs to me that I could use the much > shorter: > > def experience_text(self): > return dict(CHOICES).get("self.level", "???") > > So, the question is, purely as a matter of readability, which

Re: A question of style (finding item in list of tuples)

On Mon, May 21, 2012 at 10:37 PM, Roy Smith wrote: > The above code works, but it occurs to me that I could use the much > shorter: > >    def experience_text(self): >        return dict(CHOICES).get("self.level", "???") > > So, the question is, purely as a matter of readability, which would you >

A question of style (finding item in list of tuples)

I've got this code in a django app: CHOICES = [ ('NONE', 'No experience required'), ('SAIL', 'Sailing experience, new to racing'), ('RACE', 'General racing experience'), ('GOOD', 'Experienced racer'), ('ROCK', 'Rock star'), ] def experience_

Re: Einstein summation notation (was: question of style)

Steven D'Aprano writes: > Since I haven't specified an implementation for assemble_page, it could > be doing *anything*. Perhaps it has to talk to a remote database over a > slow link, perhaps it generates 300 lines of really inefficient HTML code > with no content, perhaps it sends a print job

Re: Einstein summation notation (was: question of style)

On Fri, 17 Jul 2009 07:12:51 -0700, Paul Rubin wrote: > Steven D'Aprano writes: >> def assemble_page(header, body, footer): >> if header or body or footer: >> do_lots_of_expensive_processing() >> else: >> do_nothing_gracefully() > > Why should the processing be expensive

Re: Einstein summation notation (was: question of style)

Steven D'Aprano writes: > def assemble_page(header, body, footer): > if header or body or footer: > do_lots_of_expensive_processing() > else: > do_nothing_gracefully() Why should the processing be expensive if all three fields are empty? > if header or body or footer:

Re: Einstein summation notation (was: question of style)

On Fri, 17 Jul 2009 00:34:00 -0700, Paul Rubin wrote: > Steven D'Aprano writes: >> It is very useful to be able to write e.g.: >> >> if header or body or footer: >> print assemble_page(header, body, footer) >> >> and have empty strings to be equivalent to False. > > Why doesn't assemble_pag

Re: question of style

> koranthala (k) wrote: >>> That test was designed to treat None as a boolean False, without >>> noticing that numeric 0 is also treated as False and could make the >>> test do the wrong thing. This is an extremely common type of error. >k> Actually, I felt that 0 not being considered False

Re: Einstein summation notation (was: question of style)

Steven D'Aprano writes: > It is very useful to be able to write e.g.: > if header or body or footer: > print assemble_page(header, body, footer) > and have empty strings to be equivalent to False. Why doesn't assemble_page properly handle the case where header, body, and footer are all empty?

Re: Einstein summation notation (was: question of style)

On Thu, 16 Jul 2009 23:13:51 -0700, koranthala wrote: >> That test was designed to treat None as a boolean False, without >> noticing that numeric 0 is also treated as False and could make the >> test do the wrong thing. This is an extremely common type of error. > > Actually, I felt that 0 not

Re: Einstein summation notation (was: question of style)

On Thu, Jul 16, 2009 at 11:13 PM, koranthala wrote: >> That test was designed to treat None as a boolean False, without >> noticing that numeric 0 is also treated as False and could make the >> test do the wrong thing.  This is an extremely common type of error. > > Actually, I felt that 0 not bein

Re: Einstein summation notation (was: question of style)

> That test was designed to treat None as a boolean False, without > noticing that numeric 0 is also treated as False and could make the > test do the wrong thing. This is an extremely common type of error. Actually, I felt that 0 not being considered False would be a better option. I had lot of

Einstein summation notation (was: question of style)

Albert van der Horst wrote: Einstein introduced the summation convention for indices that are used twice. Leaving out summation signs is absolutely hideous, but it has saved generations of physicists of loosing track (and their minds.) There is a joke among mathematicians that if Einstein hadn'

Re: question of style

In article <7x8wj2agma@ruckus.brouhaha.com>, Paul Rubin wrote: >Steven D'Aprano writes: >> > but I don't accept that "somethingness" >> > vs. "nothingness" is the same distinction as truth vs falsehood. >> >> It's the distinction used by Python since the dawn of

Re: question of style

In article <7x8wj4uxnb@ruckus.brouhaha.com>, Paul Rubin wrote: > >Anyway, Python's overloading of bool(...) is yet another misfeature >and although it's convenient, the "explicit is better than implicit" >principle indicates to avoid that sort of trick. Well, tr

Re: A question of style .....

tuxagb: > If I have to write an extension module with many objects, how can I > organizing the code? > I think: every object in a separate file, and a last file with the > PyInit_. function. But is unmenageable . > > Solutions? What do you think about using Cython? Bye, bearophile -- htt

A question of style .....

If I have to write an extension module with many objects, how can I organizing the code? I think: every object in a separate file, and a last file with the PyInit_. function. But is unmenageable . Solutions? Thanks! -- http://mail.python.org/mailman/listinfo/python-list

Re: question of style

Simon Forman writes: > BTW, Paul, kind of a tangent: I reimplemented the same algorithm but > using tuples instead of instances (and empty tuples for "NULL" > values.) I was trying to mess around in the space you seemed to > indicate existed, i.e. a better implementation using other datatypes, >

Re: question of style

Steven D'Aprano writes: > > but I don't accept that "somethingness" > > vs. "nothingness" is the same distinction as truth vs falsehood. > > It's the distinction used by Python since the dawn of time. Python only > grew a bool type a few versions back. That's true, part of the situation we have

Re: question of style

Paul Rubin wrote: I don't know what a furphy is, but I don't accept that "somethingness" vs. "nothingness" is the same distinction as truth vs falsehood. True and False are values in a specific datatype (namely bool), not abstract qualities of arbitrary data structures. The idea that the "if"

Re: question of style

Steven D'Aprano wrote: > On Sun, 05 Jul 2009 11:37:49 +, Lie Ryan wrote: > >> Neither python's `if` nor `if` in formal logic is about testing True vs. >> False. `if` in python and formal logic receives a statement. The >> statement must be evaluatable to True or False, but does not have to be

Re: question of style

On Sun, 05 Jul 2009 06:12:25 -0700, Paul Rubin wrote: >> There are three natural approaches to (say) re.search() for dealing >> with failure: >> >> (1) return a sentinel value like None; (2) return a matchobject which >> tests False; (3) raise an exception. > > 4. Have re.search return a bool an

Re: question of style

On Sun, 05 Jul 2009 11:37:49 +, Lie Ryan wrote: > Neither python's `if` nor `if` in formal logic is about testing True vs. > False. `if` in python and formal logic receives a statement. The > statement must be evaluatable to True or False, but does not have to be > True or False themselves. It

Re: question of style

On Sun, 05 Jul 2009 03:08:16 -0700, Paul Rubin wrote: > Steven D'Aprano writes: >> > Yes, it saves a few keystrokes to say "if x:" instead of "if >> > len(x)==0:" or even "if bool(x):", >> >> It's not about saving keystrokes -- that's a furphy. It's about >> encapsulation. Objects are in a bette

Re: question of style

Steven D'Aprano writes: > > I wouldn't say Python's None is terrible,... > No, wait, I tell I lie... re.search() sometimes bites me, because > sometimes it returns None and sometimes it returns a matchobject and I > don't use re often enough to have good habits with it yet. re is a common sourc

Re: question of style

Paul Rubin wrote: > Steven D'Aprano writes: >> "if len(x) == 0" is wasteful. Perhaps I've passed you a list-like >> iterable instead of a list, and calculating the actual length is O(N). > > That doesn't happen in any of Python's built-in container types. I > could see some value to having a g

Re: question of style

Steven D'Aprano writes: > > Yes, it saves a few keystrokes to say "if x:" instead of "if > > len(x)==0:" or even "if bool(x):", > > It's not about saving keystrokes -- that's a furphy. It's about > encapsulation. Objects are in a better position to recognise when they > are "something" (true)

Re: question of style

On Sat, 04 Jul 2009 23:17:21 -0700, Paul Rubin wrote: > Steven D'Aprano writes: >> Certain people -- a tiny minority -- keep trying to argue that the >> ability to say "if obj" for arbitrary objects is somehow a bad thing, >> and their arguments seem to always boil down to: "If you write code >>

Re: question of style

Steven D'Aprano writes: > Certain people -- a tiny minority -- keep trying to argue > that the ability to say "if obj" for arbitrary objects is somehow a bad > thing, and their arguments seem to always boil down to: > "If you write code that assumes that only bools have a truth value, then > su

Re: question of style

On Sat, 04 Jul 2009 11:10:48 -0700, Paul Rubin wrote: > Anyway, Python's overloading of bool(...) is yet another misfeature and > although it's convenient, the "explicit is better than implicit" > principle indicates to avoid that sort of trick. "Overloading of bool()"? I don't understand what t

Re: question of style

On Jul 4, 2:10 pm, Paul Rubin wrote: > Simon Forman writes: > > > if not (self.higher and self.lower): > > >     return self.higher or self.lower > > > That would work too in this case, both higher and lower are expected > > to be either None or an object (that doesn

Re: question of style

Simon Forman writes: > > if not (self.higher and self.lower): > >     return self.higher or self.lower > > That would work too in this case, both higher and lower are expected > to be either None or an object (that doesn't override the default all- > objects-are-true rule.) -1. Objects can supp

Re: question of style

In article <7xws6oa862@ruckus.brouhaha.com>, Paul Rubin wrote: > >In many cases it later turns out that list really was the natural >representation and it ends up growing additional potential elements. >I saw some article about database design recently that claim

Re: question of style

On Jul 4, 2:03 am, upwestdon wrote: > On Jul 2, 1:23 pm, Simon Forman wrote: > > > > > Hey I was hoping to get your opinions on a sort of minor stylistic > > point. > > These two snippets of code are functionally identical. Which would you > > use and why? > > The first one is easier [for me anyw

Re: Re: question of style

upwestdon wrote: On Jul 2, 1:23 pm, Simon Forman wrote: Hey I was hoping to get your opinions on a sort of minor stylistic point. These two snippets of code are functionally identical. Which would you use and why? The first one is easier [for me anyway] to read and understand, but slightly l

Re: question of style

a...@pythoncraft.com (Aahz) writes: > AFAICT, in order for Maybe and Option to work, you need to have some > kind of static typing system. Am I missing something? I'm not sure. Maybe there could be some kind of syntactic support in a dynamic language (not that I'm suggesting adding that to Pytho

Re: question of style

upwestdon wrote: if not (self.higher and self.lower): return self.higher or self.lower self.lower = 0 self.higher = 123 ??? More than just None is False -- http://mail.python.org/mailman/listinfo/python-list

Re: question of style

On Jul 2, 1:23 pm, Simon Forman wrote: > Hey I was hoping to get your opinions on a sort of minor stylistic > point. > These two snippets of code are functionally identical. Which would you > use and why? > The first one is easier [for me anyway] to read and understand, but > slightly less efficie

Re: question of style

In article <7xhbxtjxtn@ruckus.brouhaha.com>, Paul Rubin wrote: >Simon Forman writes: >> >> (I like Haskell's Maybe, but saying A is better than B doesn't imply >> that B is therefore terrible.) > >I wouldn't say Python's None is terrible, but the programming st

Re: question of style

On Fri, 03 Jul 2009 13:50:12 -0700, Paul Rubin wrote: > I wouldn't say Python's None is terrible, but the programming style in > which None is used as a marker for "absent value" is genuinely a source > of bugs, requiring care when used. Often it's easy to just avoid it and > all the bugs that co

Re: question of style

On Jul 3, 4:50 pm, Paul Rubin wrote: > I wouldn't say Python's None is terrible, but the > programming style in which None is used as a marker > for "absent value" is genuinely a source of bugs, > requiring care when used.  Often it's easy to just > avoid it and all t

Re: question of style

Simon Forman writes: > "...stick to the principle: NULL is wrong because it causes horrible > and tricky mistakes which appear even after the program was tested > thoroughly. You cannot introduce NULL into the language and tell the > programmer to be careful about it. The programmer is not capable

Re: question of style

On Jul 3, 12:56 am, Paul Rubin wrote: > Simon Forman writes: > > > Yes, but the concept of null pointers is considered kludgy these days. > > Seriously? "kludgy"?  (I really AM getting old.) > >  http://math.andrej.com/2009/04/11/on-programming-language-design/ > > d

Re: question of style

On Jul 3, 2:09 am, Lie Ryan wrote: > Simon Forman wrote: > > On Jul 2, 3:57 pm, Scott David Daniels wrote: > >> Duncan Booth wrote: > >>> Simon Forman wrote: > ... > if self.higher is self.lower is None: return > ... > >>> As a matter of style however I wouldn't use the shorthand

Re: question of style

Simon Forman wrote: Hey I was hoping to get your opinions on a sort of minor stylistic point. These two snippets of code are functionally identical. Which would you use and why? The first one is easier [for me anyway] to read and understand, but Easier for you but not for those who are familia

Re: question of style

On 2009-07-03, Steven D'Aprano wrote: > On Thu, 02 Jul 2009 22:14:18 +, Tim Harig wrote: >> On 2009-07-02, Paul Rubin wrote: >>> Tim Harig writes: If lower is 5 and higher is 3, then it returns 3 because 3 != None in the first if. >>> Sorry, the presumption was that lower <= higher

Re: question of style

On Thu, 02 Jul 2009 22:14:18 +, Tim Harig wrote: > On 2009-07-02, Paul Rubin wrote: >> Tim Harig writes: >>> If lower is 5 and higher is 3, then it returns 3 because 3 != None in >>> the first if. >> Sorry, the presumption was that lower <= higher, i.e. the comparison >> had already been mad

Re: question of style

Paul Rubin wrote: > Lie Ryan writes: >> I guess in python, None as the missing datum idiom is still quite prevalent: > > Well, sometimes there is no way around it, but: > >> def cat_list(a=None, b=None): >> # poor man's list concatenation >> if a is None and b is None: return [] >> i

Re: question of style

On Thu, 02 Jul 2009 21:56:40 -0700, Paul Rubin wrote: >> Well I wouldn't know, I've been fortunate enough to program mostly in >> python for over half a decade now and None and 0 are as close as I've >> gotten to NULL in a long time. > > Right, and how many times have you had to debug > >Att

Re: question of style

Lie Ryan writes: > I guess in python, None as the missing datum idiom is still quite prevalent: Well, sometimes there is no way around it, but: > def cat_list(a=None, b=None): > # poor man's list concatenation > if a is None and b is None: return [] > if a is None: return b > if

Re: question of style

Simon Forman wrote: > Hey I was hoping to get your opinions on a sort of minor stylistic > point. > These two snippets of code are functionally identical. Which would you > use and why? If self is an object (and it must have been), it would be preferrable to set self.higher and self.lower to a kno

Re: question of style

Paul Rubin wrote: > Tim Harig writes: >> That being the case, it might be a good idea either to handle the situation >> and raise an exception or add: >> >> assert self.lower <= self.higher >> >> That way an exception will be raised if there is an error somewhere else >> in the code rather then si

Re: question of style

Lie Ryan wrote: > Tim Harig wrote: >>> Speaking only to the style issue, when I've wanted to do something like >>> that, I find: >>>if self.higher is None is self.lower: >>> more readable, by making clear they are both being compared to a >>> constant, rather than compared to each other. >>

Re: question of style

Paul Rubin wrote: > Generally, having a special > value like None to denote a missing datum was considered standard > practice a few decades ago, I guess in python, None as the missing datum idiom is still quite prevalent: def cat_list(a=None, b=None): # poor man's list concatenation if

Re: question of style

Simon Forman wrote: > On Jul 2, 3:57 pm, Scott David Daniels wrote: >> Duncan Booth wrote: >>> Simon Forman wrote: ... if self.higher is self.lower is None: return ... >>> As a matter of style however I wouldn't use the shorthand to run two 'is' >>> comparisons together, I'd write

Re: question of style

Tim Harig wrote: >> Speaking only to the style issue, when I've wanted to do something like >> that, I find: >>if self.higher is None is self.lower: >> more readable, by making clear they are both being compared to a >> constant, rather than compared to each other. > > By comparing them to

Re: question of style

Simon Forman writes: > > Yes, but the concept of null pointers is considered kludgy these days. > Seriously? "kludgy"? (I really AM getting old.) http://math.andrej.com/2009/04/11/on-programming-language-design/ discusses the issue (scroll down to "Undefined values" section). > Well I wouldn

Re: question of style

On Jul 2, 9:30 pm, Paul Rubin wrote: > Simon Forman writes: > > This code is part of a delete() method for a binary tree > > implementation. "None" is used to simulate a NULL pointer. In the case > > where both children are non-None the code goes on to handle that. >

Re: question of style

Simon Forman writes: > This code is part of a delete() method for a binary tree > implementation. "None" is used to simulate a NULL pointer. In the case > where both children are non-None the code goes on to handle that. > > None is a "unitary" or "singleton" value, so "is" is the right > compari

Re: question of style

Tim Harig writes: > > Well, that assert is not right because you have to handle the case > > where one of the values is None... > Sorry, it worked under 2.5: Well, it didn't crash under 2.5. Whether the result was correct is a different question. > None seems to have been evaluated less the

Re: question of style

On Jul 2, 3:57 pm, Scott David Daniels wrote: > Duncan Booth wrote: > > Simon Forman wrote: > >> ... > >> if self.higher is self.lower is None: return > >> ... > > As a matter of style however I wouldn't use the shorthand to run two 'is' > > comparisons together, I'd write that out in full if it

Re: question of style

On Jul 2, 4:08 pm, Erik Max Francis wrote: > Simon Forman wrote: > > Hey I was hoping to get your opinions on a sort of minor stylistic > > point. > > These two snippets of code are functionally identical. Which would you > > use and why? > > The first one is easier [for me anyway] to read and und

Re: question of style

On 2009-07-02, Tim Harig wrote: > Sorry, it worked under 2.5: [SNIP] > None seems to have been evaluated less then any integer. The same isn't > true under 3.0: None seem to have been evaluated less then any non-negative integer including 0. -- http://mail.python.org/mailman/listinfo/python-lis

Re: question of style

On 2009-07-02, Paul Rubin wrote: > Tim Harig writes: >> That being the case, it might be a good idea either to handle the situation >> and raise an exception or add: >> assert self.lower <= self.higher >> That way an exception will be raised if there is an error somewhere else >> in the code rath

Re: question of style

Tim Harig writes: > That being the case, it might be a good idea either to handle the situation > and raise an exception or add: > > assert self.lower <= self.higher > > That way an exception will be raised if there is an error somewhere else > in the code rather then silently passing a possibly

Re: question of style

On 2009-07-02, Paul Rubin wrote: > Tim Harig writes: >> If lower is 5 and higher is 3, then it returns 3 because 3 != None in the >> first if. > Sorry, the presumption was that lower <= higher, i.e. the comparison > had already been made and the invariant was enforced by the class > constructor.

Re: question of style

Tim Harig writes: > If lower is 5 and higher is 3, then it returns 3 because 3 != None in the > first if. Sorry, the presumption was that lower <= higher, i.e. the comparison had already been made and the invariant was enforced by the class constructor. The comment should have been more explicit

Re: question of style

On 2009-07-02, Paul Rubin wrote: [reformated with emphasis added] >#self.higher and self.lower are each either "available" (i.e. are not >#None), or unavailable (are None). [EMPHASIS] Return the highest of the >#available values. [/EMPHASIS] If no value is available, return None. Y

Re: question of style

On 2009-07-02, Scott David Daniels wrote: > Duncan Booth wrote: >> Simon Forman wrote: >> As a matter of style however I wouldn't use the shorthand to run two 'is' >> comparisons together, I'd write that out in full if it was actually needed >> here. That part I don't really have a problem wit

Re: question of style

Simon Forman wrote: Hey I was hoping to get your opinions on a sort of minor stylistic point. These two snippets of code are functionally identical. Which would you use and why? The first one is easier [for me anyway] to read and understand, but slightly less efficient, while the second is [margi

Re: question of style

Simon Forman writes: > ## Second snippet > > if self.higher is None: > if self.lower is None: > return > return self.lower > if self.lower is None: > return self.higher > > What do you think? I'm not sure, but my guess is that what you are really trying to write is something

Re: question of style

Duncan Booth wrote: Simon Forman wrote: ... if self.higher is self.lower is None: return ... As a matter of style however I wouldn't use the shorthand to run two 'is' comparisons together, I'd write that out in full if it was actually needed here. Speaking only to the style issue, when I'

Re: question of style

On 2009-07-02, Duncan Booth wrote: > so apart from reversing the order of the comparisons once you've dropped > the redundant test it is the same as the first one. I try to evaluate what you have given regardless of what Booth pointed out. So, I will only evaluate the first line as it contains m

Re: question of style

Simon Forman writes: > These two snippets of code are functionally identical. Which would you > use and why? Both are terrible. I can't tell what you're really trying to do. As Terry Reedy points out, the case where self.higher and self.lower are both not None is not handled. If you want to ex

Re: question of style

Simon Forman wrote: Hey I was hoping to get your opinions on a sort of minor stylistic point. These two snippets of code are functionally identical. Which would you use and why? The first one is easier [for me anyway] to read and understand, but slightly less efficient, while the second is [margi

Re: question of style

the fact that you felt compelled to explain the "one minor point" in the first snippet tells me that the second snippet does not need that explanation and will be easier for someone (like you for example) to maintain in the future. Second snippet would be my choice. Kee Nethery On Jul 2, 20

Re: question of style

On Jul 2, 1:44 pm, Duncan Booth wrote: > Simon Forman wrote: > > Hey I was hoping to get your opinions on a sort of minor stylistic > > point. > > These two snippets of code are functionally identical. Which would you > > use and why? > > The first one is easier [for me anyway] to read and unders

Re: question of style

Simon Forman wrote: > Hey I was hoping to get your opinions on a sort of minor stylistic > point. > These two snippets of code are functionally identical. Which would you > use and why? > The first one is easier [for me anyway] to read and understand, but > slightly less efficient, while the seco

question of style

Hey I was hoping to get your opinions on a sort of minor stylistic point. These two snippets of code are functionally identical. Which would you use and why? The first one is easier [for me anyway] to read and understand, but slightly less efficient, while the second is [marginally] harder to follo