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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com