[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 21:24:06 CEST 2005


Jim Jewett <jimjjewett at gmail.com> wrote:
> 
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Josiah Carlson wrote:
> 
> >> This has the benefit that an arbitrary block of code can be named, 
> >> and a named TerminateBlock used to exit it.
> 
> >> ... I suspect any such implementation is going to need to use
> >> exceptions for the guts of the flow control, even if that use isn't
> >> visible to the programmer.
> 
> > Not necessarily.  If I were implementing such a thing; any time
> > arbitrary break/continues (to a loop that isn't the deepest) were used
> > in nested loops, I would increment a counter any time a loop was entered,
> > and decrement the counter any time a loop was exited.  ...
> 
> When named blocks are used in Lisp, they often cross function
> boundaries.  Given that, the number of intervening loops could
> change depending on external variables.  Since you would have
> to pop frames anyhow, Exceptions are the right way to do it.

I wasn't talking about cross-function blocks/named blocks.  I was
strictly talking about nested loops as they currently exist in Python.


> If you limited the named-block gotos to within a single function/method,
> then the loop counter would work (and you could limit obfuscation).
> Unfortunately, you would lose most of the power of named blocks, 
> while still paying the full ugliness price.

That's fine, I don't want named loops or blocks anyhow.  I was merely
offering an implementation that did not require exceptions, and was
necessarily fast (proving both that it could be fast and not require
exceptions).


> You would also encourage 
> people to inline things that ought to be separate functions.

I wouldn't go that far.  If one were to introduce such functionality, it
would be to ease control flow within nested for/while/blocks.  Whether
or not that lead to people inlining code, who are we to say?  It would,
however, complicate the 'inline function' decorator that I seem to have
lost my link to.


> In case it isn't clear, I think named loops would be a mistake.  I
> wanted them when I first started, but ... at the moment, I can't
> think of any usage that wasn't an ugly speed hack, which is at
> least more explicit with the "raise Found" idiom.

Don't get me wrong, I think they would be a mistake as well, but they
would solve the 'does a break statement in a block break its enclosing
loop' question, as well as general nested loop flow control issues.  Now
that we both agree that they shouldn't be done, maybe one of us should
write a PEP for Guido to rule on so that we never have to hear about
loop naming (heh).


 - Josiah



More information about the Python-Dev mailing list