On 10/14/2010 2:21 PM, Cameron Simpson wrote:
On 14Oct2010 14:13, Tim Chase wrote:
| On 10/14/10 12:53, Paul Rubin wrote:
|>Carl Banks writes:
|>>In general, the only way to test if a generator is empty is to try to
|>>consume an item. (It's possible to write an iterator that consumes an
|>>i
On 2010-10-15, Albert Hopkins wrote:
> On Fri, 2010-10-15 at 14:54 +, Grant Edwards wrote:
>> > so you could test for emptiness, look ahead at the next item without
>> > consuming it, etc.
>>
>> And what happens when the generator is doing things like executing
>> database transactions?
>
>
On Fri, 2010-10-15 at 14:54 +, Grant Edwards wrote:
> > so you could test for emptiness, look ahead at the next item without
> > consuming it, etc.
>
> And what happens when the generator is doing things like executing
> database transactions?
You should also add prediction to the caching.
On 2010-10-14, Paul Rubin wrote:
> Carl Banks writes:
>
>> In general, the only way to test if a generator is empty is to try to
>> consume an item. (It's possible to write an iterator that consumes
>> an item and caches it to be returned on the next next(), and whose
>> boolean status indicates
Paul Rubin writes:
> Steven D'Aprano writes:
>> (4) Expensive generators. The beauty of generators is that they produce
>> values on demand. Making all generators cache their first value means
>> that you pay that cost even if you end up never needing the first value.
>
> You wouldn't generate
On Oct 14, 7:08 pm, Paul Rubin wrote:
> Steven D'Aprano writes:
> > (4) Expensive generators. The beauty of generators is that they produce
> > values on demand. Making all generators cache their first value means
> > that you pay that cost even if you end up never needing the first value.
>
> Yo
On 10/14/10 20:48, Steven D'Aprano wrote:
(3) Generators with side-effects. I know, I know, if you write functions
with side-effects, you're in a state of sin already, but there's no need
for Python to make it worse.
(4) Expensive generators. The beauty of generators is that they produce
values
On Thu, 14 Oct 2010 14:43:29 -0400, Albert Hopkins wrote:
> There may be times, however, that a generator may "know" that it
> doesn't/isn't/won't generate any values, and so you may be able to
> override boolean evaluation. Consider this example:
[snip example]
This is a good example, but it'
Steven D'Aprano writes:
> (4) Expensive generators. The beauty of generators is that they produce
> values on demand. Making all generators cache their first value means
> that you pay that cost even if you end up never needing the first value.
You wouldn't generate the cached value ahead of ti
On Thu, 14 Oct 2010 14:13:30 -0500, Tim Chase wrote:
>> I remember thinking that Python would be better off if all generators
>> automatically cached an item, so you could test for emptiness, look
>> ahead at the next item without consuming it, etc. This might have been
>> a good change to make i
On Oct 14, 10:53 am, Paul Rubin wrote:
> Carl Banks writes:
> > In general, the only way to test if a generator is empty is to try to
> > consume an item. (It's possible to write an iterator that consumes an
> > item and caches it to be returned on the next next(), and whose
> > boolean status i
On 14Oct2010 14:13, Tim Chase wrote:
| On 10/14/10 12:53, Paul Rubin wrote:
| >Carl Banks writes:
| >>In general, the only way to test if a generator is empty is to try to
| >>consume an item. (It's possible to write an iterator that consumes an
| >>item and caches it to be returned on the next
On 10/14/10 12:53, Paul Rubin wrote:
Carl Banks writes:
In general, the only way to test if a generator is empty is to try to
consume an item. (It's possible to write an iterator that consumes an
item and caches it to be returned on the next next(), and whose
boolean status indicates if there'
On Thu, 2010-10-14 at 10:16 +0100, Tony wrote:
> I have been using generators for the first time and wanted to check for
> an empty result. Naively I assumed that generators would give
> appopriate boolean values. For example
>
> def xx():
> l = []
> for x in l:
> yield x
>
> y = xx()
>
Carl Banks writes:
> In general, the only way to test if a generator is empty is to try to
> consume an item. (It's possible to write an iterator that consumes an
> item and caches it to be returned on the next next(), and whose
> boolean status indicates if there's an item left. ...)
I remember
On Oct 14, 6:36 am, Peter Otten <__pete...@web.de> wrote:
> * I would recommend that you avoid the above approach. Pythonic solutions
> favour EAFP (http://docs.python.org/glossary.html#term-eafp) over look-
> before-you-leap:
>
> try:
> value = next(y)
> except StopIteration:
> print "ran
On Oct 14, 2:16 am, Tony wrote:
> I have been using generators for the first time and wanted to check for
> an empty result. Naively I assumed that generators would give
> appopriate boolean values. For example
>
> def xx():
> l = []
> for x in l:
> yield x
>
> y = xx()
> bool(y)
>
> I e
Tony wrote:
> I have been using generators for the first time and wanted to check for
> an empty result. Naively I assumed that generators would give
> appopriate boolean values. For example
>
> def xx():
> l = []
> for x in l:
> yield x
>
> y = xx()
> bool(y)
>
>
> I expected the la
On 14Oct2010 10:16, Tony wrote:
| I have been using generators for the first time and wanted to check for
| an empty result. Naively I assumed that generators would give
| appopriate boolean values. For example
|
| def xx():
| l = []
| for x in l:
| yield x
|
| y = xx()
| bool(y)
|
|
19 matches
Mail list logo
