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

Ron Adam rrr at ronadam.com
Sun May 8 08:52:33 CEST 2005


Josiah Carlson wrote:

> For is already tuned to be as fast as possible, which makes sense; it is
> used 4,523 times in Python 2.4.0's standard library, and easily hundreds
> of thousands of times in user code.  Changing the standard for loop is
> not to be done lightly.

Agreed!

>>And why this isn't just as good:
>>
>>     try:
>>         for value in iterator:
>>             BLOCK1
>>     except StopIteration:
>>         BLOCK2
>>
>>Is one extra line that bad?
> 
> 
> I don't know what line you are referring to.

Was referring to the 'try'., the 'except' would be in place of the else.

Nick pointed out this wouldn't work as the 'for' already catches the 
StopIteration exception.


>>I think a completely separate looping or non-looping construct would be 
>>better for the finalization issue, and maybe can work with class's with 
>>__exit__ as well as generators.
> 
> From what I understand, the entire conversation has always stated that
> class-based finalized objects and generator-based finalized objects will
> both work, and that any proposal that works for one, but not the other,
> is not sufficient.

That's good to hear.  There seems to be some confusion as to weather or 
not 'for's will do finalizing.  So I was trying to stress I think 
regular 'for' loops should not finalize. They should probably give an 
error if an object with an try-finally in them or an __exit__ method. 
I'm not sure what the current opinion on that is.  But I didn't see it 
in any of the PEPs.

>>Having it loop has the advantage of making it break out in a better 
>>behaved way.
> 
> What you have just typed is nonsense.  Re-type it and be explicit.

It was a bit brief, sorry about that. :-)

To get a non-looping block to loop, you will need to put it in a loop or 
put a loop in it.

In the first case, doing a 'break' in the block doesn't exit the loop. 
so you need to add an extra test for that.

In the second case, doing a 'break' in the loop does exit the block, but 
finishes any code after the loop.  So you may need an extra case in that 
case.

Having a block that loops can simplify these conditions, in that a break 
alway exits the body of the block and stops the loop.  A 'continue' can 
be used to skip the end of the block and start the next loop early.

And you still have the option to put the block in a loop or loops in the 
block and they will work as they do now.

I hope that clarifies what I was thinking a bit better.


Ron_Adam





























More information about the Python-Dev mailing list