[Python-Dev] PEP 340 -- loose ends

[Phillip J. Eby]

At 05:55 PM 5/2/05 -0700, Guido van Rossum wrote:
>3. I'm leaning against Phillip's proposal; IMO it adds more complexity
>for very little benefit.

Little benefit, I'll agree with, even though there are EIBTI and TOOWTDI 
benefits as well as Errors Should Never Pass Silently.  But the only added 
implementation complexity is the decorator -- balanced against the removal 
of the need for a 'next()' builtin.  I also believe that the approach 
actually *reduces* pedagogical complexity by not allowing any blurring 
between the concept of an iterator and the concept of a block template.

Since I'm not sure if anybody besides you is aware of what I proposed, I'll 
attempt to recap here, and then step to allow discussion.  If there's no 
community support, I'll let it die a natural death, because it's ultimately 
a "purity" question rather than a practical one, though I think that other 
people who teach Python programming should weigh in on this.

Specifically, I propose that PEP 340 *not* allow the use of "normal" 
iterators.  Instead, the __next__ and __exit__ methods would be an 
unrelated protocol.  This would eliminate the need for a 'next()' builtin, 
and avoid any confusion between today's iterators and a template function 
for use with blocks.

Because today's generators were also not written with blocks in mind, it 
would also be necessary to use a @decorator to declare that a generator is 
in fact a block template.  Possibly something like:

     @blocktemplate
     def retry(times):
         for i in xrange(times):
             try:
                 yield
             except StopIteration:
                 return
             except:
                 continue
             else:
                 return
         raise

My argument is that this is both Explicit (i.e., better than implicit) and 
One Obvious Way (because using existing iterators just Another Way to do a 
"for" loop).  It also doesn't allow Errors (using an iterator with no 
special semantics) to Pass Silently.

Of course, since Practicality Beats Purity, I could give this all up.  But 
I don't think the Implementation is Hard to Explain, as it should be just 
as easy as Guido's proposal.  Instead of a 'next()' builtin, one would 
instead implement a 'blocktemplate' decorator (or whatever it's to be 
called).  The same __next__/__exit__/next methods have to be implemented as 
in Guido's proposal.  Really, the only thing that changes is that you get a 
TypeError when a template function returns an iterator instead of a block 
template, and you have to use the decorator on your generators to 
explicitly label them safe for use with blocks.  (Hand-crafted block 
templates still just implement __next__ and __exit__, in the same way as 
they would under Guido's proposal, so no real change there.)

Guido may also have other reasons to take a different direction that he may 
not have expressed; e.g. maybe in Py3K there'll be no "for", just "iter(x) 
as y:"?  Or...?

I don't claim to have any special smarts about this, but other people 
(including Guido) have previously expressed reservations about the 
near-blending of iteration and block control that PEP 340 allows.  So, I've 
thrown out this proposal as an attempt to address those reservations.  YMMV.