Re: [Python-Dev] Small any/all enhancement
Eric Nieuwland wrote: all(o==0 for o in some_objects) ? all() can be terminated at the first false element. For very long sequences this has important performance benefits. Besides, it makes all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... And so does the version with generator expressions: Alex' expression will also terminate with the first false statement; it is equivalent to some_objects[0]==0 and some_objects[1]==0 and ... Regards, Martin ___ 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] Small any/all enhancement
On Dec 27, 2005, at 11:06 PM, Eric Nieuwland wrote: ... def zerop(x): return x==0 all(some_objects, zerop) and why would that be better than all(o==0 for o in some_objects) ? all() can be terminated at the first false element. For very long sequences this has important performance benefits. Besides, it makes Of course it can -- in both formulations. genexp's are also computed as needed, only one item at a time: you appear to imply they don't, maybe you're confusing them with list comprehensions. What I'm asking is, what are the ADVANTAGES of the pred form, that make it worth paying the conceptual cost of having two obvious ways to do one task. all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... ...and also the equivalent of all(pred(s) for s in seq) -- which is exactly my problem: I don't like redundant good ways of expressing identical tasks. The genexp will often be more compact, whenever the 'pred' requires a def, a lambda, or something like operator.attrgetter, anyway. 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] Small any/all enhancement
I wrote: all() can be terminated at the first false element. For very long sequences this has important performance benefits. Besides, it makes all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... then, Martin v. Löwis wrote: And so does the version with generator expressions: Alex' expression will also terminate with the first false statement; it is equivalent to some_objects[0]==0 and some_objects[1]==0 and ... and Alex Martelli wrote: Of course it can -- in both formulations. genexp's are also computed as needed, only one item at a time: you appear to imply they don't, maybe you're confusing them with list comprehensions. What I'm asking is, what are the ADVANTAGES of the pred form, that make it worth paying the conceptual cost of having two obvious ways to do one task. all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and pred(seq[2]) and ... ...and also the equivalent of all(pred(s) for s in seq) -- which is exactly my problem: I don't like redundant good ways of expressing identical tasks. The genexp will often be more compact, whenever the 'pred' requires a def, a lambda, or something like operator.attrgetter, anyway. Oops! Right you are. I was a bit too quick after seeing the use of map() proposed. --eric ___ 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] Small any/all enhancement
I see that Python 2.5 will include a simple implementation of any/all.
What I would like to ask, before it's too late, is if it's possible to add an
optional test argument.
any(iterable, test=bool) and all(iterable, test=bool)
These would be the new proposed APIs. The usecase is to be able to extract
attributes from objects or simply to have arbitrary checks like:
import operator
any(some_objects, test=operator.attrgetter('some_attribute'))
or
def zerop(x):
return x==0
all(some_objects, zerop)
instead of preprocessing the generator with a generator expression before
passing it to any/all.
Thanks.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
pgpm3YZZLyclq.pgp
Description: PGP signature
___
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] Small any/all enhancement
Valentino Volonghi aka Dialtone wrote:
What I would like to ask, before it's too late, is if it's possible to add an
optional test argument.
I don't see why: you can easily synthesize that with map/imap.
These would be the new proposed APIs. The usecase is to be able to extract
attributes from objects or simply to have arbitrary checks like:
import operator
any(some_objects, test=operator.attrgetter('some_attribute'))
So write
any(map(operator.attrgetter('some_attribute'), some_objects))
# same number of characters to type
any(o.some_attribute for o in some_objects)
# fewer number of characters
def zerop(x):
return x==0
all(some_objects, zerop)
So write
all(map(some_objects, zerop))
or
all(o==0 for o in some_objects)
# avoids defining zerop
instead of preprocessing the generator with a generator expression before
passing it to any/all.
What is the disadvantage of such preprocessing?
Regards,
Martin
___
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] Small any/all enhancement
On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
...
any(iterable, test=bool) and all(iterable, test=bool)
...
any(some_objects, test=operator.attrgetter('some_attribute'))
Why would that be better than
any(o.some_attribute for o in some_objects)
?
def zerop(x):
return x==0
all(some_objects, zerop)
and why would that be better than
all(o==0 for o in some_objects)
?
instead of preprocessing the generator with a generator expression
before
passing it to any/all.
I guess I just don't see the advantage, along any plane, since the
genexp fits so snugly right there inside the any/all's parentheses.
What am I missing?
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] Small any/all enhancement
On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote: I'll answer here for all the people who kindly answered. Why would that be better than any(o.some_attribute for o in some_objects) ? I think it's because lately I've been using common lisp a lot and the approach with the test function is pretty common there. Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. One reason was to hide the iteration from the user and let python handle it, but I can see that this is both not enough and probably not even so necessary since the iteration protocol is already 'hidden' when using for..in. What am I missing? Nothing, it's just me and the bad influence that lisp has on my mind :). Sorry to bother the list then. Thanks for the kind replies. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de pgpeKPBtN4P2s.pgp Description: PGP signature ___ 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] Small any/all enhancement
On Dec 27, 2005, at 5:48 PM, Valentino Volonghi aka Dialtone wrote: On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote: I'll answer here for all the people who kindly answered. Why would that be better than any(o.some_attribute for o in some_objects) ? I think it's because lately I've been using common lisp a lot and the approach with the test function is pretty common there. Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. I think that generator/list expressions are more common practice than attrgetter/itemgetter, so I'm not even sure it's clearer. I don't see the harm in a key argument like sorted has, but without a key argument it could be extended to take more arguments like max/ min do for convenience. e.g. any(a, b, c) instead of any((a, b, c)). -bob ___ 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] Small any/all enhancement
Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. If there is to be any enhancement, I think I would prefer it to be an enhancement to map, so that map's second and subsequent arguments can be sequences or iterables, and its result is an iterable if any of its arguments is an iterable. Unfortunately, that would be an incompatible change :-( ___ 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] Small any/all enhancement
Bob Ippolito wrote: I don't see the harm in a key argument like sorted has, but without a key argument it could be extended to take more arguments like max/ min do for convenience. e.g. any(a, b, c) instead of any((a, b, c)). Hmm, I think you just found the use case for fixing the current lack of support for keyword-only arguments - it allows conveniences like this, while still allowing keyword arguments to tailor function behaviour. For example, min max could grow a key argument analogous to sorted's (e.g. to find the person with the highest score in a list of players). (Guido's already approved the concept of permitting keyword arguments to be supplied after a * entry in a function call. I don't remember if he expressed an opinion on allowing the same syntax in a function definition to define keyword only arguments). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Small any/all enhancement
Alex Martelli wrote:
On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
...
any(iterable, test=bool) and all(iterable, test=bool)
...
any(some_objects, test=operator.attrgetter('some_attribute'))
Why would that be better than
any(o.some_attribute for o in some_objects)
?
def zerop(x):
return x==0
all(some_objects, zerop)
and why would that be better than
all(o==0 for o in some_objects)
?
all() can be terminated at the first false element. For very long
sequences this has important performance benefits. Besides, it makes
all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and
pred(seq[2]) and ...
___
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
