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

[Ron Adam]

Josiah Carlson wrote:

> 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.

So you can be re-re-convinced if more use cases are found? ;-)


>>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.

Well I happen to like stacks for somethings. They can be very useful and 
efficient.  But I agree that they have been horrible abused in all sorts 
of ways.  But that doesn't make them bad.  In this case I think they 
work well, but the implementation ccould be improved.

I see a correlation between breaks, continues, and exceptions.  So it 
makes since to me that they could use similar mechanisms to catch and 
reraise them as needed.

But this seems awkward and it's even *uglier*!

     try:
        # some code in a loop.
     except BreakException, Breakme:
        pass

then later....

     raise Breakme    # breaks a loop now instead of then.


But these examples sort of point out an underlying concept in these 
discussions.  That it is useful to be able to postpone or delay code to 
be executed at a later time.  Thus the idioms, before-after, enter-exit, 
and init-finalize.  And here again,  with try-finally, and breaks/continues.

_Ron


> 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 .

Changing it just for the sake of newness or "it's cool" or whatever 
isn't good of course.  But extending a language vs changing the way it 
works, is worth while as long as it's done in a careful and consistent 
manner.  That's sort of why I'm against changing 'for', and for adding 
the new loop/block.  I see it as a loop with a higher level of 
abstraction. A new tool to be used in new ways, but I want to keep my 
old dependable tools too.


_Ron

The simplest computer language in the world is called MAIN, has only one 
function called main(), which evaluates any arbitrary set of arguments 
you give it.  Programming is now an obsolete profession!

However we are now in desperate need of experts who can understand 
exceedingly long arbitrary sets of arguments and what they will do when 
they are evaluated by MAIN's main() function.

;-)