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 w
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
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 ...
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
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 curr
> 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 m
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
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 f
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):
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
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 ex
11 matches
Mail list logo
