Re: bool evaluations of generators vs lists

2009-02-24 Thread Antoon Pardon
On 2009-02-10, Albert Hopkins mar...@letterboxes.org wrote: On Tue, 2009-02-10 at 12:50 -0800, Josh Dukes wrote: I don't understand what you mean by this. But if you really want to know if a generator is non-empty: def non_empty(virgin_generator): try: virgin_generator.next()

bool evaluations of generators vs lists

2009-02-10 Thread Josh Dukes
quite simply...what??? In [108]: bool([ x for x in range(10) if False ]) Out[108]: False In [109]: bool( x for x in range(10) if False ) Out[109]: True Why do these two evaluate differently? I was expecting that they would evaluate the same but the generator would return true *as soon as the

Re: bool evaluations of generators vs lists

2009-02-10 Thread Chris Rebert
On Tue, Feb 10, 2009 at 11:15 AM, Josh Dukes josh.du...@microvu.com wrote: quite simply...what??? In [108]: bool([ x for x in range(10) if False ]) Out[108]: False This evaluates the list comprehension and creates an empty list, which is considered boolean False by Python. In [109]: bool( x

Re: bool evaluations of generators vs lists

2009-02-10 Thread Albert Hopkins
On Tue, 2009-02-10 at 11:15 -0800, Josh Dukes wrote: quite simply...what??? In [108]: bool([ x for x in range(10) if False ]) Out[108]: False In [109]: bool( x for x in range(10) if False ) Out[109]: True Why do these two evaluate differently? I was expecting that they would evaluate

Re: bool evaluations of generators vs lists

2009-02-10 Thread Josh Dukes
The first example is a list. A list of length 0 evaluates to False. The second example returns a generator object. A generator object apparently evaluates to true. Your example is not iterating of their values of the generator, but evaluating bool(generator_object) itself. My feeling is

Re: bool evaluations of generators vs lists

2009-02-10 Thread Albert Hopkins
On Tue, 2009-02-10 at 12:50 -0800, Josh Dukes wrote: The thing I don't understand is why a generator that has no iterable values is different from an empty list. Why shouldn't bool == has_value?? Technically a list, a tuple, and a string are also objects but if they lack values they're

Re: bool evaluations of generators vs lists

2009-02-10 Thread Steven D'Aprano
On Tue, 10 Feb 2009 12:50:02 -0800, Josh Dukes wrote: The thing I don't understand is why a generator that has no iterable values is different from an empty list. How do you know it has no iterable values until you call next() on it and get StopIteration? By the way, your has_values function

Re: bool evaluations of generators vs lists

2009-02-10 Thread Chris Rebert
On Tue, Feb 10, 2009 at 1:57 PM, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 10 Feb 2009 12:50:02 -0800, Josh Dukes wrote: The thing I don't understand is why a generator that has no iterable values is different from an empty list. How do you know it has no iterable

Re: bool evaluations of generators vs lists

2009-02-10 Thread Josh Dukes
ahhh any! ok, yeah, I guess that's what I was looking for. Thanks. On 10 Feb 2009 21:57:56 GMT Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Tue, 10 Feb 2009 12:50:02 -0800, Josh Dukes wrote: The thing I don't understand is why a generator that has no iterable values is

Re: bool evaluations of generators vs lists

2009-02-10 Thread Terry Reedy
Josh Dukes wrote: I was actually aware of that (thank you, though, for trying to help). What I was not clear on was if the boolean evaluation is a method of an object that can be modified via operatior overloading (in the same way + is actually .__add__()) or not. Clearly __nonzero__ is the

Re: bool evaluations of generators vs lists

2009-02-10 Thread Gabriel Genellina
On Tue, 2009-02-10 at 12:50 -0800, Josh Dukes wrote: The thing I don't understand is why a generator that has no iterable values is different from an empty list. Why shouldn't bool == has_value?? Technically a list, a tuple, and a string are also objects but if they lack values they're