[Python-ideas] Relax __exit__ method to be a generator

Andrew Svetlov andrew.svetlov at gmail.com
Sun Apr 6 21:02:55 CEST 2014


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


More information about the Python-ideas mailing list