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

[Josiah Carlson]

Ron Adam <rrr at ronadam.com> wrote:
> 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? ;-)

Historically, my opinion has meant close to 0 in regards to language
features, so even if I were to change my mind again, I doubt it would
have any effect on the outcome of this feature.

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

You missed my point.  As an implementation detail, stacks are fine.  As
discussion about how one uses it, discussion of stacks is wholly out of
the question.

Think of it in terms of function calls.  Do we talk about 'call stacks'
when we make function calls?  Of course not, and call stacks are a major
part about how Python is implemented.  This tells us that we certainly
shouldn't talk about 'loop stacks' when we are talking about nested
loops.


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

That's why we don't see many (if any) uses right now, even if it does
solve the nested loop control flow 'problem'.


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

Apple, Apple, Apple, Apple, hotdog.  One of those don't quite fit, and
that's break/continue.  Break/continue statements are about control flow,
and while the other mechanisms can be used for control flow, that is not
their primary purpose.  The first three are about resource
acquisition/release and try/finally is about making sure that a block of
code is executed "no matter what" (the first three using try/finally as
a mechanism to guarantee resource release, if acquisition has taken
place).

Let us look at the flow of the conversation...
"There should be a resource acquisition/release statement with a code
suite attached."
... lead to ...
"The behavior of a break within such a code suite is ambiguous."
... lead to ...
"Flow within nested loops themselves can be tricky and/or ambiguous."

It's not that there is an underlying concept, it's just that the third
bit of the conversation hadn't been brought up, but 'solving' that bit
would unambiguate the previous 'break within code block' ambiguity. 
It's a sledge hammer solution to a jewel hammer problem.


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

In general, I was thinking "that would make my life as a programmer
working with Python easier", but within a few days I realize that
Python's power is in its simplicity.  With every new language
ability/feature, learning and using the language (necessarily) becomes
more difficult.


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

I'm not sure that the discussion has been leading toward a change that
is 'careful and consistent', but more of people offering their pet
desired syntaxes (I've been having dejavu to the decorator discussion of
last spring/summer).  Of course the only person you need to convince is
Guido, and he's already all but signed off on the entirety of PEP 340; we
seem to be within syntax musings right now.


 - Josiah