[Python-Dev] Enhancing PEP 310 (or conflating, your decision :-) (original) (raw)

Holger Krekel pyth at devel.trillke.net
Sun Jan 4 06:43:19 EST 2004

hello python-dev, and hello Michael and Paul,

here are, eventually, some remarks, ideas and food for thought regarding PEP 310.

++ with with yield

The 'with' as proposed by PEP 310 implements semantics that you can today implement with a try-finally construct. (see the PEP for explanation). But I think that we can make PEP 310 do better than try-finally in that we can allow yield inside with-blocks.

Let's recap PEP 310 quickly:

__enter__ is called upon entering a with code block 
__exit__  is called upon leaving a with code block
          (should be renamed '__leave__' which i do subsequently :-)

Compared to the try-finally statement we explicitely have some crucial information: the enter method which encapsulates the prepare/acquire code for the block. Thus we could specifically allow:

with handler():
    for x in someiter:
        yield x

and define the semantics so that handler.enter is called every time the generator frame resumes execution and handler._leave when it is suspended/destroyed [*]. (It may also be feasible to indicate the specific reason for leaving the code block (suspend/finish) to the leave method or probably better to call another method).

PEP325 proposes a coarser-grained "close" method on generators that is triggered when the generator has finished work. In constract, the above semantic extension of PEP 310 allows finer-grained locking as seen when using locks/critical regions as it directly allows yield within try-finally-alike semantics.

++ with and exceptions

In an independent consideration, it would be useful if we had a way to react on exceptions from the with-object, say with an except method that retrieves exceptions from 'its' code block. I am not sure, however, that this can be implemented in a straight forward way (Michael commented on this earlier with a similar sentiment IIRC). But it does seem to be a nice abstraction that you can provide an object that encapsulates how you deal with exceptions because you can change exception-handling code in one place instead of possibly many scattered try-finally/except-locations.

++ with loops

In another independent consideration, we could extend PEP 310 to enable loop-constructs: the leave method returns True if it wants the interpreter to revisit the code-block. Well this one is really more food for thought more than anything else but ... taking and combinining the above ideas we might be able to make

with line in file(somefn): # work with line (probably even yield it ...)

the file is guaranteed to be closed here!

work with clean semantics. Hmmm, IIRC Armin Rigo had a similar suggestion to reuse the 'for' statement instead of introducing a new with-keyword alltogether. This doesn't sound too far away now, anymore :-)

++

cheers and a happy new year,

holger

[*] disclaimer: I am not entirely sure if this can be implemented in a straight forward way but it shouldn't be too hard :-)

More information about the Python-Dev mailing list