[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:27:09 CEST 2005


Ron Adam <rrr at ronadam.com> wrote:
> 
> Josiah Carlson wrote:
> 
>  > Ron Adam <rrr at ronadam.com> wrote:
>  >
>  >> There's also the possibility to use conditional looping based on the 
> value returned from the generator.
>  >>
>  >> do VAR from EXPR if VAR==CONST:
>  >>    BLOCK
>  >>
>  >> This is a bit verbose, but it reads well. :-)
>  >
>  >
>  >
>  > Reading well or not, this is not really an option for the same reasons
>  > why...
>  >
>  >   for VAR in EXPR1 if EXPR2:
>  > or
>  >   for VAR in EXPR1 while EXPR2:
>  >
>  > are not options.  Keep it simple.
>  >
> 
> Yes, so just "do [VAR from] EXPR1:"

Regardless of the 'finalization' syntax, I'm talking about the fact that
including extra 'if EXPR' or 'while EXPR' is not going to be an option.

>  >>    3.  Do-loops: An generator based loop with finalization:  This 
> could be both single and multiple pass.  The difference is determined by 
> weather or not the generator used loops the yield statement or not.
>  >
>  >
>  > Offering only generator-based finalization loops is, as I understand it,
>  > not an option.
> 
> It could also include classes with __exit__ methods which are really 
> just more complex generators when used this way.
> 
> But isn't this what PEP340 *already* proposes?  Or am I missing a subtle 
> distinction here.

It is, in fact, what PEP 340 already proposes.  Let us take a step back
for a moment and realize that this entire discussion is going around in
circles.

From what I understand, we all agree:
1. There should be some mechanism X which signals that an indented suite
is a 'block statement'.  Such blocks are described and finalized as per
PEP 340 (or whatever derivative gets accepted).

2. Standard for/while loops should not be finalized in a timely fashion,
because testing for the proper methods would necessarily slow down large
amounts of current Python, so should be left to the garbage collector.

3. A note as to the additional overhead of finalized blocks should be
mentioned in the source code of the finalization implementation, and a
note on their performace characteristics may or may not need to be
listed in the language reference.

What there is still discussion over:
4. What the syntax should be.
5. Whether or not it loops.
6. Method names.


I find the answers to 4,5,6 to be a matter of opinion, and like many, I
have my own.  However, I do not feel strongly enough about 4,5,6 to
argue about my opinion (I've been attempting to re-state where the
conversation went for the last 2 weeks, as I have managed to read each
and every email about the subject at hand *ick*).

 - Josiah



More information about the Python-Dev mailing list