[Python-Dev] pep 310 (reliable acquisition/release pairs)

Samuele Pedroni pedronis at bluewin.ch
Mon Sep 22 14:19:16 EDT 2003


At 19:41 22.09.2003 +0200, Holger Krekel wrote:
>Michael Hudson wrote:
> > Holger Krekel <hpk at trillke.net> writes:
> > > The PEP actually is about interacting with the execution
> > > of a code block.  It allows to define (one-shot) interception points
> > > for entering and leaving a code block.  Now there are at least
> > > two interesting cases which the PEP does (quite explicitely) not cover:
> > >
> > > - what to do with exceptions
> > >
> > > - what to do with yield
> > >
> > > IMHO introducing a new block statement at this stage in language
> > > development warrants an effort to tackle these cases (and maybe more
> > > like e.g. allowing the handler to trigger looping).
> > >
> > > This is probably best done with trying to directly design a protocol 
> between
> > > the "interpreter-loop" and the - what i'd call - the "execution 
> handler".
> >
> > Well, in writing PEP 310 (as I suspect you know) I was aiming for a
> > simple, almost entirely syntactic way of shortening a common pattern.
> > You seem to be gunning for something far deeper here.
>
>Hmmm, introducing a new block statement just for "shortening a common
>pattern" doesn't sound like a sufficient reason to me.  OTOH i'd try to argue
>that in order to add reliable resource synchronization an effort to get
>it working in the context of exceptions and generators would add more
>than just a macro :-)
>
>Also thinking more along the lines of Armin's alternative idea
>(incorporate it in into the for-loop protocol) is interesting as
>it avoids adding a new keyword which seems of great value to me.

can we avoid to have now the discussion that we don't wanted now.


>on a side note, it would be great if we could soon (after integration of the
>parser/compiler) branch off PyPy to do quick experiments with different
>approaches.  IIRC Guido mentioned at EuroPython that this might
>be an interesting use of PyPy (to easily test new language features).
>This way it's also easier for PyPy to keep up to date :-)

I won't say anything, see above, BUT ... 




More information about the Python-Dev mailing list