Changing all() and any() to take multiple arguments
I believe that the all() and any() library functions should be modified to accept multiple arguments as well as single iterators. Currently, code such as this (taken from a sublime text plugin), breaks: def is_enabled(self): return all( self.connected, not self.broadcasting, self.mode is 'client' ) Meaning either that one must write either this, and use parenthesis to avoid some obscure order of operations error: def is_enabled(self): return ( (self.connected) and (not self.broadcasting) and (self.mode is 'client') ) Or this, and have others wonder at the odd double parenthesis or list: def is_enabled(self): return (( self.connected, not self.broadcasting, self.mode is 'client' )) I can't foresee any compatibility issues for this modification, as it would only make currently broken code work, not the other way around. I searched the mailing list archives with Google to see if there were any past discussions on this topic, however the ambiguousness my search terms ('all', 'any' 'multiple, 'arguments') meant that the results were too numerous for me to sort through ( I gave up after the first 3 pages). Clay Sweetser "The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it. " - Terry Pratchett
On Sun, Aug 25, 2013 at 11:50 PM, Clay Sweetser <clay.sweetser@gmail.com> wrote:
I can't foresee any compatibility issues for this modification, as it would only make currently broken code work, not the other way around.
This is not a strong point in your idea's favor. If people are shipping broken code such as your example which would be a TypeError, there are any number of things they should be doing before we change the function.
From: Clay Sweetser <clay.sweetser@gmail.com> Sent: Sunday, August 25, 2013 9:50 PM
I believe that the all() and any() library functions should be modified to accept multiple arguments as well as single iterators.
But that would make a number of expressions ambiguous. Is all([0, 0, 0]) true because it has one true argument, or false because it has three false arguments? What about all([0])? Or all([]), or all()? Even if you invented rules for which interpretation wins in these cases, it would still be ambiguous to human readers. Especially in cases where (as usual) the arguments aren't actually a static list display, but a variable, comprehension, or other expression. There are a few places in Python where we have such ambiguity, such as giving the string % operator a single value, but I don't think most people think that's a good thing. In fact, a few such cases were eliminated in Python 3.0, and newer functions like str.format or itertools.chain all avoid it.
Currently, code such as this (taken from a sublime text plugin), breaks: def is_enabled(self): return all( self.connected, not self.broadcasting, self.mode is 'client' )
Meaning either that one must write either this, and use parenthesis to avoid some obscure order of operations error: def is_enabled(self): return ( (self.connected) and (not self.broadcasting) and (self.mode is 'client') )
Do you really think anyone doesn't know that the dot in "self.connected" binds more tightly than "and"? The fact that you can add excessive parentheses doesn't that mean you should, or that most people do. And really, I think this is more readable than the way you'd like to write it. For a short, static sequence, "all" is just extra verbiage getting in the way—exactly as in English, where you wouldn't say "All of John, Mary, and Pete went to the ceremony."
On Mon, Aug 26, 2013 at 2:50 PM, Clay Sweetser <clay.sweetser@gmail.com> wrote:
Meaning either that one must write either this, and use parenthesis to avoid some obscure order of operations error: def is_enabled(self): return ( (self.connected) and (not self.broadcasting) and (self.mode is 'client') )
I'd be inclined toward this option, especially if some of your expressions are complex checks - the 'and' will short-circuit, a tuple won't. It looks perfectly readable, to me. Side point: I'd be cautious about using 'is' with strings, unless you have some way of guaranteeing that both sides have been interned. ChrisA
On Aug 26, 2013 3:24 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
On Mon, Aug 26, 2013 at 2:50 PM, Clay Sweetser <clay.sweetser@gmail.com>
wrote:
Meaning either that one must write either this, and use parenthesis to avoid some obscure order of operations error: def is_enabled(self): return ( (self.connected) and (not self.broadcasting) and (self.mode is 'client') )
I'd be inclined toward this option, especially if some of your expressions are complex checks - the 'and' will short-circuit, a tuple won't. It looks perfectly readable, to me. Side point: I'd be cautious about using 'is' with strings, unless you have some way of guaranteeing that both sides have been interned. Heh, I had actually changed that snippet somewhat from its original source. My own code uses many constants, so it's something like "MODE is CLIENT_TO_CLIENT" (The way commands in sublime text are written makes it almost mandatory to use globals in order to share state).
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
participants (4)
-
Andrew Barnert -
Brian Curtin -
Chris Angelico -
Clay Sweetser