[Python-Dev] PEP 380 (yield from a subgenerator) comments

[Nick Coghlan]

I really like the PEP - it's a solid extension of the ideas introduced
by PEP 342.

The two changes I would suggest is that the PEP be made more explicit
regarding the fact that the try/finally block only enclose the yield
expression itself (i.e. no other parts of the containing statement) and
that the caching comment be updated with a list of specific semantic
elements that the caching should not affect.

For the first part, I would prefer if the example was changed to use
capitals for the variant non-keyword parts of the statement:

  RESULT = yield from EXPR

And that it formally expanded to:

  _i = iter(EXPR)
  try:
      _u = _i.next()
      while 1:
          try:
              _v = yield _u
          except Exception, _e:
              _m = getattr(_i, 'throw', None)
              if _m is not None:
                  _u = _m(_e)
              else:
                  raise
          else:
              if _v is None:
                  _u = _i.next()
              else:
                  _u = _i.send(_v)
  except StopIteration, _e:
      _expr_result = _e.value
  finally:
      _m = getattr(_i, 'close', None)
      if _m is not None:
          _m()
  RESULT = _expr_result

I believe writing it that way would make it clearer that the scope of
the try/finally block doesn't include the assignment part of the statement.

For the second part, the specific semantics that I believe should be
noted as not changing even if an implementation chooses to cache the
bound methods are these:

- The "send" and "throw" methods of the subiterator should not be
retrieved if those methods are never called on the delegating generator

- If "send" is called on the delegating generator and the subiterator
has no "send" method, then an appropriate "AttributeError" should be
raised in the delegating generator

- If retrieving the "next", "send" or "throw" methods from the
subiterator results in an exception then the subiterator's "close"
method (if it has one) should still be called

Cheers,
Nick.

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