Nick Coghlan wrote:
> Ron Adam wrote:
>
>>I agree, re-using or extending 'for' doesn't seem like a good idea to me.
>
>
> I agree that re-using a straight 'for' loop is out, due to performance and
> compatibility issues with applying finalisation semantics to all such
> iterative
> loops (there's a reason the PEP redraft doesn't suggest this).
>
> However, it makes sense to me that a "for loop with finalisation" should
> actually *be* a 'for' loop - just with some extra syntax to indicate that the
> iterator is finalised at the end of the loop.
Question: Is the 'for' in your case iterating over a sequence? or is it
testing for an assignment to determine if it should continue?
The difference is slight I admit, and both views can be said to be true
for 'for' loops iterating over lists also. But maybe looking at it as a
truth test of getting something instead of an iteration over a sequence
would fit better? When a variable to assign is not supplied then the
test would be of a private continue-stop variable in the iterator or a
StopIteration exception.
> However, as you say, 'del' isn't great for the purpose, but I was trying to
> avoid introduding yet another keyword.
I didn't say, that was Josiah, but I agree 'del' is not good.
>An obvious alternative is to use
> 'finally' instead:
>
> for [finally] [VAR in] EXPR:
> BLOCK1
> else:
> BLOCK2
>
> It still doesn't read all that well, but at least the word more accurately
> reflects the semantics involved.
How about:
<keyword?> [VAR from] EXPR:
Could 'from' be reused in this context?
If the keyword chosen is completely different from 'for' or 'while',
then it doesn't need a 'del' or 'finally' as that can be part of the new
definition of whatever keyword is chosen.
I suggested reusing 'while' a few days ago because it fit the situation
well, but come to the conclusion reusing either 'for' or 'while' should
both be avoided.
So you might consider 'do', Guido responded with the following the other
day:
#quote
>[Greg Ewing]
>> How about 'do'?
>>
>> do opening(filename) as f:
>> ...
>>
>> do locking(obj):
>> ...
>>
>> do carefully(): # :-)
>> ...
I've been thinking of that too. It's short, and in a nostalgic way
conveys that it's a loop, without making it too obvious. (Those too
young to get that should Google for do-loop. :-)
I wonder how many folks call their action methods do() though.
#endquote
So it's not been ruled out, or followed though with, as far as I know.
And I think it will work for both looping and non looping situations.
> The last option is to leave finalisation out of the 'for' loop syntax, and
> introduce a user defined statement to handle the finalisation:
Yes, leaving it out of 'for' loop syntax is good.
I don't have an opinion on user defined statements yet. But I think
they would be somewhat slower than a built in block that does the same
thing. Performance will be an issue because these things will be nested
and possibly quite deeply.
>>I wonder how much effect adding, 'for-next' and the 'StopIteration'
>>exception check as proposed in PEP340, will have on 'for''s performance.
>
> I'm not sure what you mean here - 'for' loops already use a StopIteration
> raised
> by the iterator to indicate that the loop is complete. The code you posted
> can't
> work, since it also intercepts a StopIteration raised in the body of the loop.
Oops, meant that to say 'for-else' above ...
The 'else' is new isn't it? I was thinking that putting a try-except
around the loop does the same thing as the else. Unless I misunderstand
it's use.
But you are right, it wouldn't work if the loop catches the StopIteration.
>>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.
>
>
> The PEP redraft already proposes a non-looping version as a new statement.
> However, since generators are likely to start using the new non-looping
> statement, it's important to be able to ensure timely finalisation of normal
> iterators as well.
Huh? I thought a normal iterator or generator doesn't need
finalization? If it does, then it's not normal. Has a word been coined
for iterators with try-finally's in them yet?
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
