Nick Coghlan wrote:
Hmm, with that approach, a code inspection tool like pychecker could be used
to
pick up the slack, and flag generators which have a yield inside a
try/finally
or a user defined statement without applying the needs finalisation
decorator
What about giving them an
Greg Ewing wrote:
Nick Coghlan wrote:
Hmm, with that approach, a code inspection tool like pychecker could
be used to pick up the slack, and flag generators which have a yield
inside a try/finally or a user defined statement without applying
the needs finalisation decorator
What about
Ron Adam wrote:
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.
But if the
Ron Adam [EMAIL PROTECTED] wrote:
The argument over whether blocks should loop, I believe has been had;
they should. The various use cases involve multi-part transactions and
such.
I think so now too, I had thought as Nick does earlier this week that
the non-looping version was
Nick Coghlan ncoghlan at gmail.com wrote:
Josiah Carlson wrote:
This has the benefit that an arbitrary block of code can be named,
and a named TerminateBlock used to exit it.
... I suspect any such implementation is going to need to use
exceptions for the guts of the flow control, even if
Greg Ewing wrote:
Ron Adam wrote:
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.
Jim Jewett [EMAIL PROTECTED] wrote:
Nick Coghlan ncoghlan at gmail.com wrote:
Josiah Carlson wrote:
This has the benefit that an arbitrary block of code can be named,
and a named TerminateBlock used to exit it.
... I suspect any such implementation is going to need to use
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] 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
Josiah Carlson wrote:
Ron Adam [EMAIL PROTECTED] wrote:
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.
Yes, I meant for the syntax to be the shorter form,
Raymond Hettinger wrote:
[Nick Coghlan]
The number of good use cases for a looping block statement currently
stands at
exactly 1 (auto_retry). Every other use case suggested (locking,
opening,
suppressing, etc) involves factoring out try statement boiler plate
that
is far
easier to
Ron Adam wrote:
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.
But if there's too much overlap in functionality
Josiah Carlson wrote:
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.
I'm not convinced about that. If implemented properly,
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
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
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
Josiah Carlson wrote:
Eric Nieuwland [EMAIL PROTECTED] wrote:
I don't know. Using 'del' in that place seems ackward to me.
Why not use the following rule:
for [VAR in] EXPR:
SUITE
If EXPR is an iterator, no finalisation is done.
If EXPR is not an iterator, it is created at
Ron Adam wrote:
Question: Is the 'for' in your case iterating over a sequence? or is it
testing for an assignment to determine if it should continue?
Iterating over a sequence. If it's single-pass (and always single pass), you
should use a user defined statement instead.
The difference is
On 5/8/05, Jp Calderone [EMAIL PROTECTED] wrote:
If such a construct is to be introduced, the ideal spelling would seem to
be:
for [VAR in] EXPR:
BLOCK1
finally:
BLOCK2
While I have not been following this discussion at all (I don't have
the energy or time to
Paul Moore wrote:
On 5/8/05, Jp Calderone [EMAIL PROTECTED] wrote:
If such a construct is to be introduced, the ideal spelling would seem to
be:
for [VAR in] EXPR:
BLOCK1
finally:
BLOCK2
While I have not been following this discussion at all (I don't have
the
Nick Coghlan wrote:
The whole PEP draft can be found here:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
I've updated this based on the feedback so far. The biggest change is that I've
dropped the 'del' idea in favour of an optional 'finally' clause on for loops
that finalises the
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
It's not a matter of 'will they be finalized', but instead a matter of
'will they be finalized in a timely manner'. From what I understand;
upon garbage collection, any generator-based resource will be finalized
via
Eric Nieuwland [EMAIL PROTECTED] wrote:
I suggested to create AN ITERATOR FOR THE LIST and destroy that at the
end. The list itself remains untouched.
My mistake, I did not understand your use of pronouns.
- Josiah
___
Python-Dev mailing list
Nick Coghlan wrote:
Iterating over a sequence. If it's single-pass (and always single pass), you
should use a user defined statement instead.
That's the technique suggested for the single-pass user defined statements.
However, a 'for loop with finalisation' is *still fundamentally an
Josiah Carlson wrote:
The argument over whether blocks should loop, I believe has been had;
they should. The various use cases involve multi-part transactions and
such.
Then it is not so much looping but more pushing forward the state of
the state of the block's life-cycle?
This might by a
Nick Coghlan wrote:
[...]
The whole PEP draft can be found here:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
[...]
Used as follows::
for del auto_retry(3, IOError):
f = urllib.urlopen(http://python.org/;)
print f.read()
I don't know.
Josiah Carlson wrote:
You should know why that can't work. If I pass a list, is a list an
iterator? No, but it should neither be created nor destroyed before or
after.
The discussion has been had in regards to why re-using 'for' is a
non-starter; re-read the 200+ messages in the
Ron Adam [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
You should know why that can't work. If I pass a list, is a list an
iterator? No, but it should neither be created nor destroyed before or
after.
The discussion has been had in regards to why re-using 'for' is a
On Sun, 08 May 2005 14:16:40 +1000, Nick Coghlan [EMAIL PROTECTED] 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
27 matches
Mail list logo
