Greg Ewing [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
PEP 340 is still my favorite, but it seems there's too much opposition
to it,
I'm not opposed to PEP 340 in principle, but the
ramifications seemed to be getting extraordinarily
complicated, and it seems to be hamstrung by
Phillip J. Eby wrote:
At 08:21 PM 5/16/2005 -0400, Jack Diederich wrote:
I still haven't gotten used to Guido's heart-attack inducing early
enthusiasm for strange things followed later by a simple proclamation
I like. Some day I'll learn that the sound of fingernails on the
chalkboard is
Paul Moore wrote:
On 5/17/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Previously Belaboured Point? (Just guessing from context here, but if I'm
right,
that's one acronym I'm going to have to remember. . .)
Practicality Beats Purity, surely...?
D'oh! *slaps forehead*
Cheers,
Nick.
--
Nick
Nick Coghlan wrote:
Wouldn't that mean we run the risk of suppressing a *real* SystemExit if it
occurs while a generator is being finalised?
Perhaps a new exception IteratorExit, which is a subclass of SystemExit. Then
well-behaved code wouldn't trap it accidentally, and the finalisation
[Guido van Rossum]
I'm in favor of the general idea, but would like to separate the error
injection and finalization API for generators into a separate PEP,
which would then compete with PEP 288 and PEP 325.
[Nick Coghlan]
Without that it pretty much devolves into the current version of
Nick Coghlan wrote:
Paul Moore wrote:
On 5/17/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Previously Belaboured Point? (Just guessing from context here, but if I'm
right,
that's one acronym I'm going to have to remember. . .)
Practicality Beats Purity, surely...?
D'oh! *slaps forehead*
Brett C. wrote:
Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping? It never felt like it was a
screaming mass with pitchforks but more of a I don't love it, but I can deal
crowd.
My problem with looping was that, with
Ron Adam wrote:
He should also be able to put try excepts before the yield, and after
the yield, or in the block. (But not surrounding the yield, I think.)
I was given to understand that yield is currently
allowed in try-except, just not try-finally. So
this would require a
Steven Bethard wrote:
If I've misunderstood, and there are other situations when
needs_finish is required, it'd be nice to see some more examples.
The problem is try/except/else blocks - those are currently legal, so the
programmer has to make the call about whether finalisation is needed or
On 5/15/05, Steven Bethard [EMAIL PROTECTED] wrote:
Having done the python-dev summary on this topic,
You have my deepest sympathy :-)
So in some sense, PEP 340 was the reason for the lack of enthusiasm;
with the semantics laid out, people were forced to deal with a specific
implementation
[Guido]
In rev 1.10 I moved the __enter__ call out of the
try-block again. Having it inside was insane: when __enter__ fails, it
should do its own cleanup rather than expecting __exit__ to clean up
after a partial __enter__.
[Ka-Ping Yee]
No, it wasn't insane. You had a good reason for
At 04:57 PM 5/16/2005 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
Also, one question: will the do protocol be added to built-in resource
types? That is, locks, files, sockets, and so on?
One person proposed that and it was shot down by Greg Ewing. I think
it's better to require a
At 09:53 PM 5/16/2005 +1000, Nick Coghlan wrote:
My PEP punts on providing a general API for passing exceptions into
generators
by making it an internal operation.
Actually, the proposals you made almost subsume PEPs 288 and 325. All
you'd need to do is:
1. move the '__del__' code to a
Greg Ewing wrote:
Brett C. wrote:
Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping? It never felt like it was a
screaming mass with pitchforks but more of a I don't love it, but I can deal
crowd.
My problem with
[Guido (responding to Fredrik Lundh's intuitive -1 on PEP 343)]
Would it be better if we pulled back in the generator exit handling
from PEP 340? That's a pretty self-contained thing, and would let you
write try/finally around the yield.
[Nick Coghlan]
That would be good, in my opinion. I
In article [EMAIL PROTECTED],
Phillip J. Eby [EMAIL PROTECTED] wrote:
...
I personally think that StopIteration, TerminateIteration,
KeyboardInterrupt and perhaps certain other exceptions should derive from
some base class other than Exception (e.g. Raisable or some such) to help
with the
[Ron Adam]
So I was wondering if something like the following is feasible?
[...]
with opening(file1,m),opening(file2,m),opening(file3,m) as f1,f2,f3:
# do stuff with files
The 'with' (or whatever) statement would need a little more under the
hood, but it might simplify handling
On Mon, May 16, 2005 at 06:24:59PM +1200, Greg Ewing wrote:
Brett C. wrote:
Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping? It never felt like it was a
screaming mass with pitchforks but more of a I don't love
At 08:21 PM 5/16/2005 -0400, Jack Diederich wrote:
I still haven't gotten used to Guido's heart-attack inducing early
enthusiasm for strange things followed later by a simple proclamation
I like. Some day I'll learn that the sound of fingernails on the
chalkboard is frequently followed by candy
Guido van Rossum wrote:
[Fredrik Lundh]
unlike the original design, all you get from this is
the ability to add try/finally blocks to your code
without ever writing a try/finally-clause (neither
in your code or in the block controller). that
doesn't strike me as especially pythonic.
Would
Shane Hathaway wrote:
Here is example A, a non-looping block statement using try:
text = 'diamond'
for fn in filenames:
try opening(fn) as f:
if text in f.read():
print 'I found the text in %s' % fn
break
That's a pretty way to
Shane Hathaway wrote:
Guido van Rossum wrote:
Consider an application where you have to acquire *two* locks regularly:
You really have to write it like this:
Shane, you've already solved this one more elegantly:
def lockBoth():
return combining(lock1.locking(), lock2.locking())
On 5/14/05, Brett C. [EMAIL PROTECTED] wrote:
Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping? It never felt like it was a
screaming mass with pitchforks but more of a I don't love it, but I can deal
crowd.
Agreed.
Shane Hathaway [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
That would be good, in my opinion. I updated PEP 3XX to use this idea:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
With that update (to version 1.6), PEP 3XX is basically PEP 343, but
injecting
exceptions
Paul Moore wrote:
On 5/14/05, Brett C. [EMAIL PROTECTED] wrote:
Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping? It never felt like it was a
screaming mass with pitchforks but more of a I don't love it, but I can deal
On 5/15/05, Paul Moore [EMAIL PROTECTED] wrote:
There were a *lot* of nice features with PEP 340. The initial
discussion had a lot of people enthusiastic about all the neat things
they could do with it. That's disappeared now, in a long series of
attempts to fix the looping issue.
Having done
Paul Moore wrote:
Looping is definitely a wart. Looping may even be a real problem in
some cases. There may be cases where an explicit try...finally remains
better, simply to avoid an unwanted looping behaviour.
I agree PEP 343 throws away too much that was good about PEP 340 - that's why
I'm
On Sun, 15 May 2005, Shane Hathaway wrote:
You might add to the PEP the following example, which could really
improve the process of building GUIs in Python:
class MyFrame(Frame):
def __init__(self):
with Panel():
with VerticalBoxSizer():
[Nick Coghlan]
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
[Steven Bethard]
there I see the semantics:
VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
exc = (None, None, None)
try:
try:
BLOCK1
except:
exc = sys.exc_info()
finally:
Guido van Rossum wrote:
Also, one question: will the do protocol be added to built-in resource
types? That is, locks, files, sockets, and so on?
One person proposed that and it was shot down by Greg Ewing. I think
it's better to require a separate wrapper.
It depends on whether the resource
A additional comment (or 2) on my previous message before I go back to
lurk mode.
If the recommended use of each resource template is kept to a single
resource, then each enter and exit can be considered a whole block of
code that will either pass or fail. You can then simplify the previous
Fredrik Lundh wrote:
try with opening(file) as f:
body
except IOError:
deal with the error (you have to do this anyway)
You don't usually want to do it right *there*, though.
More likely you'll have something further up that deals
with a variety of possible errors.
Robert Brewer wrote:
There's a typo in the code snippets at the moment.
The translation of the above statement is:
abc = EXPR
exc = () # Or (None, None, None) ?
try:
try:
VAR = abc.__enter__()
BLOCK
Guido van Rossum wrote:
I've written up the specs for my PEP 340 redux proposal as a
separate PEP, PEP 343.
http://python.org/peps/pep-0343.html
Those who have been following the thread Merging PEP 310 and PEP
340-redux? will recognize my proposal in that thread, which received
mostly
Guido van Rossum wrote:
I've written up the specs for my PEP 340 redux proposal as a
separate PEP, PEP 343.
http://python.org/peps/pep-0343.html
Those who have been following the thread Merging PEP 310 and PEP
340-redux? will recognize my proposal in that thread, which received
mostly
Fredrik Lundh wrote:
unlike the original design, all you get from this is
the ability to add try/finally blocks to your code
without ever writing a try/finally-clause (neither
in your code or in the block controller). that
doesn't strike me as especially pythonic.
I think the key benefit
On 5/14/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
PEP 343 (like PEP 310 before it) makes it possible to define the correct
resource management *once*, and then invoke it via a 'with' (or 'do')
statement.
This is probably the main point for me - encapsulate the
Paul Moore wrote:
On 5/14/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
PEP 343 (like PEP 310 before it) makes it possible to define the correct
resource management *once*, and then invoke it via a 'with' (or 'do')
statement.
This is probably the main point for me -
At 01:55 PM 5/14/2005 +0200, Fredrik Lundh wrote:
also, come to think of it, adding a new statement just to hide
try/finally statements is a waste of statement space. why not
just enhance the existing try statement? let
try with opening(file) as f:
body
except IOError:
[Fredrik Lundh]
intuitively, I'm -1 on this proposal.
So we need to do better. Do you just prefer all of PEP 340? What about
the objections against it? The mostly unnecessary loopiness in
particular?
unlike the original design, all you get from this is
the ability to add try/finally blocks to
Guido van Rossum wrote:
[Fredrik Lundh]
intuitively, I'm -1 on this proposal.
Just to toss in my opinion, I prefer PEP 340 over 343 as well, but not so much
to give 343 a -1 from me.
[SNIP - question of how to handle argument against 340 being a loop which I
never totally got since you know
Guido van Rossum wrote:
[Nick Coghlan]
Also, the call to __enter__() needs to be before the try/finally block (as it
is
in PEP 310). Otherwise we get the releasing a lock you failed to acquire
problem.
I did that on purpose. There's a separate object ('abc' in the
pseudo-code of the
Brett C. wrote:
Guido van Rossum wrote:
PEP 340 is still my favorite, but it seems there's too much opposition
to it, so I'm trying to explore alternatives; at the same time I
*really* dislike the complexities of some of the non-looping
counterproposals (e.g. Nick Coghlan's PEP 3XX or the
Guido van Rossum wrote:
[Nick Coghlan]
Also, the call to __enter__() needs to be before the try/finally block (as it
is
in PEP 310). Otherwise we get the releasing a lock you failed to acquire
problem.
I did that on purpose. There's a separate object ('abc' in the
pseudo-code of the
Guido van Rossum wrote:
I've written up the specs for my PEP 340 redux proposal as a
separate PEP, PEP 343.
http://python.org/peps/pep-0343.html
Those who have been following the thread Merging PEP 310 and PEP
340-redux? will recognize my proposal in that thread, which received
mostly
[Phillip J. Eby]
May I suggest this alternative translation in the Specification section:
abc = EXPR
__args = () # pseudo-variable, not visible to the user
try:
VAR = abc.__enter__()
try:
BLOCK
except:
[Nick Coghlan]
The stdout redirection example needs to be corrected to avoid yielding inside
a
try/finally though:
Thanks -- fixed now.
This could be left as the more elegant original if iterator finalisation (e.g.
using a __finish__() slot) came in at the same time as user defined
Guido van Rossum wrote:
I've written up the specs for my PEP 340 redux proposal as a
separate PEP, PEP 343.
http://python.org/peps/pep-0343.html
Those who have been following the thread Merging PEP 310 and PEP
340-redux? will recognize my proposal in that thread, which received
mostly
48 matches
Mail list logo
