Re: [Python-Dev] Adding any() and all()
Nick Coghlan wrote: A suggestion was made on c.l.p a while back to have a specific module dedicated to reductive operations. That is, just as itertools is oriented towards manipulating iterables and creating iterators, this module would be oriented towards consuming iterators in a reductive fashion. Is there really any need for another module just for this? The distinction between reductive and non-reductive operations on iterators seems rather too fine to me to deserve a whole new module. Why not just put them all in itertools? [1] While any()/all() read well in the context of an if statement, I think anytrue()/alltrue() better convey the reductive nature of the operations, read nearly as well in the if context, and read significantly better when isolated from the if context (e.g. assigned to a variable). I don't agree. I think 'any' and 'all' are fine names for boolean-valued functions in any context. Including 'true' in their names smacks of the same kind of redundancy as if blarg == True: ... which is widely regarded as a naive-newbie style blunder in any language. +1 on 'any' and 'all' -1 on any names including 'true' or 'false' Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of (all) things. In my mind it doesn't make sense (yet) that all(seq) returns true if all elements of seq is true and false otherwise, I would have expected all to return a list. any is better because it is very obvious it can only return one thing. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Fri, 11 Mar 2005 11:30:38 +0100, BJörn Lindqvist [EMAIL PROTECTED] wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of (all) things. In my mind it doesn't make sense (yet) that all(seq) returns true if all elements of seq is true and false otherwise, I would have expected all to return a list. any is better because it is very obvious it can only return one thing. Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. As far as the names making sense is concerned, they are perfect in context: if all(i 0 for i in int_list): if any(invalid(s) for s in input_values): While you may think that use in any other context looks a little less natural (something I'm not convinced of), in the intended context, the names seem ideal to me. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. /Peter Åstrand [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Peter Astrand wrote: On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. to extend the naming pool, FWIW CL calls similar things EVERY and SOME. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
And why not use the names already in use in numarray/Numeric ? They are called sometrue and alltrue ... IMHO, it explicits more what it means : alltrue(i5 for i in l) sometrue(i5 for i in l) Another point is: as I agree there is already a huge lot of builtins, shouldn't it be in some module ? Perhaps in itertools ? Pierre PS: It's my first post on the list, even if I'm reading it for a few months now ^_^ Peter Astrand a écrit : On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. /Peter Åstrand [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pierre.barbier%40cirad.fr -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Peter Astrand wrote: Personally, I think Python has too many builtins already. A suggestion was made on c.l.p a while back to have a specific module dedicated to reductive operations. That is, just as itertools is oriented towards manipulating iterables and creating iterators, this module would be oriented towards consuming iterators in a reductive fashion. product(), anytrue() and alltrue() were obvious candidates for inclusion ([1]). The combination of explicit for loops and a standard toolkit of reductive operations was designed to eliminate the need for reduce() ([2]). Cheers, Nick. [1] While any()/all() read well in the context of an if statement, I think anytrue()/alltrue() better convey the reductive nature of the operations, read nearly as well in the if context, and read significantly better when isolated from the if context (e.g. assigned to a variable). I also think the names are less likely to collide with existing variable names. [2] I'm firmly in Guido's camp on this one - whenever I encounter code that uses reduce(), I have to rewrite it (either mentally or literally) to use a for loop before I can understand it. Getting rid of the function would benefit me because I would no longer have to waste time figuring out what such code was doing - it would already be an explicit loop, or it would be using one of the standard reductive operations. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
[ Pierre Barbier de Reuille ]: They are called sometrue and alltrue ... IMHO, it explicits more what it means : alltrue(i5 for i in l) sometrue(i5 for i in l) +1 [ from a comment in GvR's blog ] Why not, if True in (x 42 for x in S): instead of any and why not if not False in (x 42 for x in S): instead of all? Because any and all have shortcut semantics (they return as soon as they can determine the final result). [ Guido ]: -- See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP ? In the absence of a PEP, soon will see in c.l.p discussions like: For completeness sake shouldn't there be a optimiztion version for nonetrue() ? def nonetrue(S): for x in S: if x: return False return True why not allfalse() ? Due to the previous use of sometrue(), guess it becomes easier to remeber nonetrue() than allfalse(). One may argue for aliasing(nonetrue, allfalse), and we are back to _builtin pollution_. So, people might fallback to any() and all(),realising that: '''not all()''' meaning somefalse() '''not any()''' meaning nonetrue()==allfalse() All I'm saying: +1 for the PEP. OFF-TOPIC: It is curious though that we choose to read an *implicit* True in [all(), any()] instead of an implicit False. I guess that is a moral or ethical choice coming from the Human realm, favouring Truth instead of Falsity. But that difference does not hold in the Boolean realm wink. best regards, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Adding any() and all()
BTW I definitely expect having to defend removing map/filter/reduce/lambda with a PEP; that's much more controversial because it's *removing* something and hence by definition breaking code. I suspect that lambda will be the only bone of contention. The reduce() function can be moved to the functional module. The map() and filter() functions are already covered by the itertools module. Lambda will be more difficult. Eric Raymond adapted an anti-gun control slogan and said you can pry lambda out of my cold dead hands. A bunch of folks will sorely miss the ability to create anonymous functions on the fly. When lambda is used for deferred argument evaluation (a la PEP 312), the def syntax is a crummy substitute. PS in the blog responses, a problem with sum() was pointed out -- unless you use the second argument, it will only work for numbers. Now that string concatenation is apparently O(N) rather than O(N**2) (is that right, Raymond?) maybe this could be revised. str.join() is still the best practice for string concatenation. Armin's optimization doesn't appear in other implementations of Python. In CPython, it has a set of pre-conditions that are usually but not always True. IIRC, it also doesn't apply to Unicode and ASCII mixed with Unicode. Also, the optimization is part of ceval.c and would not be triggered by sum()'s call to PyNumber_Add(). That limitation is not easily removed because the optimization depends on an interaction between the stack, variable refcounts, and the sequence of opcodes. IOW, your original pronouncement on the subject should remain in effect. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Raymond Hettinger wrote: BTW I definitely expect having to defend removing map/filter/reduce/lambda with a PEP; that's much more controversial because it's *removing* something and hence by definition breaking code. +1 on the PEP -1 on removing those tools - breaks too much code. I suspect that lambda will be the only bone of contention. The reduce() function can be moved to the functional module. The map() and filter() functions are already covered by the itertools module. Nope. Think of the side-effects that can occur as a result of calling the function argument n times with different arguments. itertools only help if the functions don't have side-effects. Iteration is nice, but not the solution to everything :-) Lambda will be more difficult. Eric Raymond adapted an anti-gun control slogan and said you can pry lambda out of my cold dead hands. A bunch of folks will sorely miss the ability to create anonymous functions on the fly. When lambda is used for deferred argument evaluation (a la PEP 312), the def syntax is a crummy substitute. While I'm no fan of lambdas either, the removal would break too much code (e.g. I have 407 hits in the code base I use regularly alone). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Mar 11, 2005, at 17:28, Guido van Rossum wrote: PS in the blog responses, a problem with sum() was pointed out -- unless you use the second argument, it will only work for numbers. Now Why is that a *problem*? It solves the end case (if the sequence is empty which you mention for any() and all() [[indeed, I think a similar approach to any and all might be best: have them return an item from the sequence, an empty sequence uses the optional second item defaulting to something reasonable -- 0 for sum, False for any, True for all, for example]] in a neatly explicit way. As I recall, I had tried to handle non-empty sequences by picking the first item and doing following + on it (with internal implementation specialcasing for strings, to avoid an attractive nuisance situation), and you cut the gordian knot by pronouncing about the second argument with a default of 0 (I immediately thought your pronouncement was excellent and I still can't see why it wouldn't be). Forcing the user to provide a 2nd arg when summing a sequence of non-numbers (say, datetime.timedelta instances, that's one example that ended up in the 2nd ed Cookbook) is good because it ensures a good return value when the sequence is empty (say, timedelta(0) rather than 0 as a number). If you're considering revisions to sum's design, my suggestion would be to find a way to let the user tell sum to use a more accurate approach when summing floats. Summing a million floats with a loop of total+=item loses a LOT of accuracy (several digits' worth!) -- but doing the summation the right way takes O(N) auxiliary temporary space, so both approaches (the naive, performance-optimized accuracy disaster, and the expensive but accurate one) should ideally be available. An optional use_partials keyword argument defaulting to False, for example, might allow that... (again, I've hopefully clarified the issues in another 2nd ed Cookbook recipe, I guess I can post that if it helps). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that
kind. Fortunately, ''.join intrinsically compensates:
x=[u'\u0fe0']*2
''.join(x)
u'\u0fe0\u0fe0'
*without* (as one would expect) the GD nuisance of converting x's items
to str (hellishly hard to document accurately and clearly, but
extremely convenient!-).
Which reminds me -- could we have a methodcaller relative to attrgetter
and itemgetter? Sort a list of strings in a case-insensitive way
would become *SO* easy with sort(dalist, key=methodcaller('lower'))...
can't REALLY recommend sort(dalist, key=str.lower) then the items of
dalist MIGHT be either str or unicode items... (the relevance of
''.join is that it proves SOMEbody considered it important to deal with
a list of either str or unicode in the joining context... why not in
the sorting context then?).
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Fri, 2005-03-11 at 14:29, Jim Jewett wrote: Is that so bad? If you plan to use them often, then from itertools import any, every +1 -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
[Guido van Rossum] But I realized (1) any() and all() read much better in their natural context (an if statement), and there's no confusion there; I do not think builtins should read good in some statement contexts and bad in the others, or designed to be legible in only a few contexts. This would be a waste. In other contexts dans `if' or `while', `any(...)' might be read as pick one of, in which case a True/False result might be surprising. `allTrue' (or such) is clearer in all contexts, even if not as nice in some of them. For `any(...)' to be clear in all contexts, it should return one of its arguments. That would surely do the proper thing in `if' or `while' context. We've read various arguments about this idea. Some (pro or con) arguments are only valid outside `if' and `while' context, other (pro and con) arguments are only valid within `if' and `while' context. If we are going to dismiss contexts outside `if' and `while', we should not retain arguments which only apply outside those contexts. This is my only complain. The overall idea and principle are good, especially if they succeed in cleaning out `reduce' and the others. However, if for compatibility reasons, `reduce' stays, than we are merely adding other ways, without sparing any, and this means yet another tiny bloat in Python, that might be better avoided. What worries me a bit about doing a PEP for this simple proposal is that it might accidentally have the wrong outcome: Isn't that true of any PEP? I thought going through a PEP for changes, and additions just as well, was not far from being a principle. Depending on opinions, the outcome is right or wrong. The principle of PEPs is not necessarily a good one in practice, as some PEPs are forever incomplete or unupdated, miss their role, and then sum up to having nearly been an annoyance. Good if PEPs may be avoided! :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Jim Jewett wrote: Guido van Rossum: [Why any() and all() shouldn't need to be imported.] Is that so bad? If you plan to use them often, then from itertools import any, every is reasonable. If you only use them once and weren't expecting it (and want your imports at the top) ... well how awful is it to have an extra line or two in your code? The problem with this approach is that any() and all() are so fundamental* that you should just use them without thinking about it, just as when you use + to conctenate strings, you don't have to stop and think to yourself, Ah, this program needs to be able to manipulate strings. I'd better make sure string operations as available in this module. Thinking such thoughts takes you away from thinking about the problem you're trying to solve by manipulating strings. Likewise, programmers solve a lot of problems with boolean expressions, and it seems silly to require a special declaration just to make the full complement of boolean operations available. I can think of three ways of coping with any() and all() being in a module: First, I could just not use them. In that case all the effort here is wasted, and my code becomes less readable than it would have been otherwise. This is the approach I usually take with modules like operator, where I can just as easily write a lambda expression (for now at least). Second, I could break my concentration to think about import statements every time I have a use for these particular functions. Third, I could import them at the top of every module. Since one of the distinguishing features of Python in a lack of gratuitous boilerplate code everywhere, I would find it very sad to add even a little bit. So while putting any() and all() into a module isn't that bad in itself, it seems like the start of a slippery slope that has Python at the top and C++ at the bottom. -- jw *I appreciate the irony of calling something fundamental when we've all gotten by just fine without it for many years--I'm trying to think from the perspective of someone used to dealing with a later (and hopefully better) version of Python. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Guido van Rossum wrote: Here's my take on the key issues brought up: Alternative names anytrue(), alltrue(): before I posted to my blog I played with these names (actually anyTrue(), allTrue(), anyFalse(), allFalse()). But I realized (1) any() and all() read much better in their natural context (an if statement), and there's no confusion there; (2) anyFalse() and allFalse() are redundant, so there's no need to distinguish between anyTrue() and anyFalse(). (To the person who wondered why we default to True: because 'if' tests for True, duh. :-) I've been using exists() and forall() in mxTools for years. The names originate from math usage, where you often use these qualifiers. A note on builtins: Most tools in mxTools automatically get registered as builtins when you load the module. The motivation for this was that wanted to have easy access to these often used APIs. However, a few years down the line I realized that this kind of usage just causes confusion when you read code: * it is not clear where the APIs originate * the code dependencies are not longer easily visible Ever since, I've switched to making all use of these functions explicit with reference to the mx.Tools module. http://www.egenix.com/files/python/mxTools.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 12 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Jim Jewett wrote: Guido van Rossum: Whether to segregate these into a separate module: they are really a very small amount of syntactic sugat, and I expect that in most cases, instead of importing that module (which totally makes me lose my context while editing) I would probably just write the extra line that it takes to get the same effect with an explicit for loop and if statement. Is that so bad? If you plan to use them often, then from itertools import any, every is reasonable. If you only use them once and weren't expecting it (and want your imports at the top) ... well how awful is it to have an extra line or two in your code? Basically the question (at least in my mind) when it comes to built-ins is whether the usage is so basic and fundamental that sticking them in a module is done more for rigid organization than for convenience. Personally, I think any() and all() meet this requirement. With their ties to basic boolean testing they should be built into the language and not just a part of the stdlib. If I am banging something out at a interpreter prompt I will want these functions easily accessible and I won't think of them as something to import. This probably comes off as wishy-washy, but it is just what my mind is spitting out at the moment. They also have the feeling as something that could be useful as a syntax (although I am just suggesting syntactic support!). Which could be an even better way to measure whether something should be a built-in. Would the function be useful as a syntactic addition to the language, but just can't quite reach the need of a new keyword? Once again any() and all() feel like that to me. These aren't *really* replacing map/filter/reduce because you're adding the new functions now, but the old-function removal is waiting until (forever?) Even if Python 3000 comes out a while from now, why wait? Two more is not that much. Besides, it isn't like we are adding functions as some crazy rate. And Guido has stated that the 2.x branch stops once 2.9 (if it goes that long) comes out. So at worst you only have to worry about 5 more releases to worry. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding any() and all()
See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP or is there a volunteer who'll add any() and all() for me? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Adding any() and all()
See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP or is there a volunteer who'll add any() and all() for me? I'll volunteer for this one. Will leave it open for discussion for a bit so that folks can voice any thoughts on the design. Raymond Hettinger ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
At 06:38 PM 3/10/05 -0800, Bill Janssen wrote: Guido, I think there should be a PEP. For instance, I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called first and last. More precisely (since S might be an iterator, or empty): def any(S): x = False for x in S: if x: break return x def all(S): x = True for x in S: if not x: break return x However, first and last don't make sense to me as names. First what? Last what? Actually, any and all don't make that much sense to me either. I find myself wanting to call them or and and, or maybe or_iter and and_iter. Or perhaps until_false or until_true. Nah, the and/or names make more sense, as they exactly match the behavior of the corresponding logical operators, if you could call them as a function. At least, if they took *args anyway. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Adding any() and all()
[Bill Janssen] I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called first and last. -1 Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. Raymond Hettinger ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. Fine, but then let's keep reduce(), which has this nice property. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Thu, Mar 10, 2005 at 10:22:45PM -0500, Raymond Hettinger wrote: [Bill Janssen] I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called first and last. -1 Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. Perl returns the last true/false value as well, and it is a subtle trap. I worked at a perl shop that had a long style guide which outlawed using that side effect but people did anyway. I'm +1 on having it return a true boolean for the same reason if (x = calc_foo()): isn't supported, if there is a quirky side effect available someone will use it and someone else won't notice. [in fact we had a guy who was downsized for doing things like calling database queries on the return value of a function that was documented as returning True/False] Perl shops require long style guides becuase perl is, ummm, perl. Python is a boon because YAGN (a style guide). The fewer side effects the better. -Jack ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
On Thu, Mar 10, 2005, Bill Janssen wrote: Raymond Hettinger: Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. +1 Fine, but then let's keep reduce(), which has this nice property. -1 -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
