[Python-ideas] yiled-from restrictions [was: x=(yield from) confusion]

Nick Coghlan ncoghlan at gmail.com
Fri Apr 10 05:16:24 CEST 2009


Jim Jewett wrote:
> [deleted file processing example, but Greg may want to add it to the
> PEP as a clear motivating use case]

It isn't really a good example - it's one of the old use cases that is
easily addressed by "for x in f: yield f" :)


> On 4/9/09, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Jacob Holm wrote:
>> For more complex cases, once caching of the methods in yield-from is
>> explicitly disallowed (as per my other message), you can do something like:
> 
> I thought part of the reason to use a generator instead of an iterator
> class was speed/efficiency, which that constraint would seem to block.
> (name lookups at each level)
> 
>>>>> def start(iterable, start):
>> ...     itr = iter(iterable)
>> ...     class TrapFirstNext(object):
>> ...       def __iter__(self):
>> ...         return self
>> ...       def next(self):
>> ...         TrapFirstNext.next = itr.next
>> ...         return start
>> ...     return TrapFirstNext()
> 
> And if that becomes a standard idiom, was anything really simplified?

Yes, because you only have to write start() once and then you can use it
as many times as you like. The big gain from yield-from is to allow code
containing a yield statement to be factored out correctly and relatively
easily even when you want to use send() and throw().

My start() example is merely intended to show that even with a
comparatively simplistic approach in the PEP that expects to be running
a fresh iterator to exhaustion every time that yield-from is used, you
can still support some fairly exotic use cases with low overhead by
dynamically updating the subiterator's methods.

The one change I am suggesting to Greg due to this is that we drop the
idea of allowing the bound methods to be cached by the implementation.
Since for loops don't cache the next() method, I no longer think the new
expression should cache any of next(), send() or throw().

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------



More information about the Python-ideas mailing list