[Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)

Josiah Carlson jcarlson at uci.edu
Mon May 9 08:40:46 CEST 2005

Ron Adam <rrr at ronadam.com> wrote:
> > The argument over whether blocks should loop, I believe has been had;
> > they should.  The various use cases involve multi-part transactions and
> > such.
> I think so now too, I had thought as Nick does earlier this week that 
> the non-looping version was cleaner, but changed my mind when I realized 
> that looping blocks could be made to work for those in a simple and 
> understandable way.

I wasn't expressing my opinion, I was attempting to express as to where
the discussion went and concluded.  I honestly can't remember having an
opinion on the subject, but I seem to have convinced Nick earlier that
they shouldn't loop, and he (re-)convinced me that indeed, they
shouldn't loop.

> I think maybe another alternative is a break buffer or cue. Where you 
> push a 'break' onto the buffer and then execute a 'break' to break the 
> current loop, The 'break' in the buffer then breaks the next loop out as 
> soon as the current loop exits, etc.


> It needs some polish I think.  ;-)

Goodness, the horror!  When implementation details start bleeding their
way into actual language constructs (using a continue/break stack in
order to control the flow of nested loops), that's a good clue that an
idea has gone a bit too far.

I would honestly prefer gotos, and I would prefer having no change to
existing syntax to gaining gotos.

It's kind of funny.  Every month I spend in python-dev, I feel less
inclined to want to change the Python language (except for the relative
import I need to finish implementing).  Not because it is a pain in the
tookus (though it is), but because many times it is my immediate sense
of aesthetics that causes me to desire change, and my future of code
maintenance makes me think forward to understanding Python 2.3 in the
context of Python 2.9 .

 - Josiah

More information about the Python-Dev mailing list