iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

New version from Greg.

This commit is contained in:
Guido van Rossum 2009-03-27 19:33:33 +00:00
parent eb61d88000
commit dcbd51055b
1 changed files with 80 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
pep-0380.txt
View File

@ -113,8 +113,9 @@ An iterator having a ``throw()`` method is expected to recognize
this as a request to finalize itself. this as a request to finalize itself.
If a call to the iterator's ``throw()`` method raises a StopIteration If a call to the iterator's ``throw()`` method raises a StopIteration
exception, and it is *not* the same exception object that was thrown exception, and it is *not* the same exception object that was thrown in,
in, its value is returned as the value of the ``yield from`` expression and the original exception was not GeneratorExit, then the value of the
new exception is returned as the value of the ``yield from`` expression
and the delegating generator is resumed. and the delegating generator is resumed.
@ -140,7 +141,6 @@ is semantically equivalent to
:: ::
_i = iter(EXPR) _i = iter(EXPR)
try:
try: try:
_y = _i.next() _y = _i.next()
except StopIteration, _e: except StopIteration, _e:
@ -156,7 +156,7 @@ is semantically equivalent to
try: try:
_y = _m(*_x) _y = _m(*_x)
except StopIteration, _e: except StopIteration, _e:
if _e is _x[1]: if _e is _x[1] or isinstance(_x[1], GeneratorExit):
raise raise
else: else:
_r = _e.value _r = _e.value
@ -175,8 +175,6 @@ is semantically equivalent to
except StopIteration, _e: except StopIteration, _e:
_r = _e.value _r = _e.value
break break
finally:
del _i
RESULT = _r RESULT = _r
except that implementations are free to cache bound methods for the 'next', except that implementations are free to cache bound methods for the 'next',
@ -249,7 +247,7 @@ so to an unfactored one in all Python implementations.
The assumption made is that, in the majority of use cases, the subiterator The assumption made is that, in the majority of use cases, the subiterator
will not be shared. The rare case of a shared subiterator can be will not be shared. The rare case of a shared subiterator can be
accommodated by means of a wrapper that blocks ``throw()`` and ``send()`` accommodated by means of a wrapper that blocks ``throw()`` and ``close()``
calls, or by using a means other than ``yield from`` to call the calls, or by using a means other than ``yield from`` to call the
subiterator. subiterator.