Literally it may be generator itself or function that returns generator object. Now I'm working on postgres library for asyncio (http://aiopg.readthedocs.org/). And I would to use *with statement* for transaction handling like: with (yield from cursor.transaction()): yield from cursor.execute(sql) The problem is: at exit of *with statement* I need to call `yield from cursor.execute('COMMIT')` or `yield from cursor.execute('ROLLBACK')`. I can do it only in __exit__ in *context manager*, but python understand only if __exit__: - returns true value, that suppresses exception from code block - returns None or any false value to propagate exception if any - raises exception itself I propose to add new rule: IF the code object is generator (co_flags & CO_GENERATOR) and __exit__ returns generator object (isinstance(ret, types.GeneratorType)) THEN do `yield from ret`. That's work fine if __exit__ itself is a *generator function* (contains `yield` or `yield from` statements): call to *generator function* returns *generator object*. The proposal: 1. Doesn't break any existing code except if user accidentally returns generator object instead of True from __exit__ call (he should not to do this and I sure this is very rare case). 2. Don't requires new syntax. asyncio itself uses: with (yield from lock): BLOCK for locking etc but unlocking for asyncio objects doesn't requires any `yield from`, so __exit__ code is just plain function but not generator. Also I can live with asyncio trick for __enter__: https://code.google.com/p/tulip/source/browse/asyncio/locks.py#156 The way is a but annoying but unrolling a value returned by __enter__ if the value is generator object will break existing code, sure. Thoughts? -- Thanks, Andrew Svetlov