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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
