[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