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 hamstru
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'
[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
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 finalisati
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.
On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > [Greg Ewing]
> >
> >>I still think it's conceptually cleaner if the object
> >>you use to access the resource is created by the
> >>__enter__ method rather than being something pre-
> >>existing, but I'm willing to co
Guido van Rossum wrote:
> [Nick Coghlan]
>
>>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 that occur into the templ
Guido van Rossum wrote:
> [Greg Ewing]
>
>>I still think it's conceptually cleaner if the object
>>you use to access the resource is created by the
>>__enter__ method rather than being something pre-
>>existing, but I'm willing to concede that PBP here.
>
>
> PBP? Google finds "Python Browser Po
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
[Greg Ewing]
> I've stopped arguing against giving with-protocol
> methods to files, etc., since it was pointed out that
> you'll get an exception if you try to re-use one.
>
> I still think it's conceptually cleaner if the object
> you use to access the resource is created by the
> __enter__ meth
Phillip J. Eby wrote:
> Why? If "with" is a "scope statement", then it doesn't make any sense
> to use it with something you intend to reuse later. The statement
> itself is an assertion that you intend to "release" the resource at the
> end of the block, for whatever "release" means to that
Guido van Rossum wrote:
> [Ron Adam]
>
>>with opening(file1,m),opening(file2,m),opening(file3,m) as f1,f2,f3:
>> # do stuff with files
>>
>
> I'm -0 on this, if only because it complicates things a fair bit for a
> very minor improvement in functionality. [...]
> It's always something we can
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 cand
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
[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 handl
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
[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 opi
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
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 'cl
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 bette
At 04:51 PM 5/16/2005 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > This makes it seem awkward for e.g. "do self.__lock", which doesn't
> > make any sense. But the extra call needed to make it "do
> > locking(self.__lock)" seems sort of gratuitous.
>
>How about
>
>do holding(self.__lock)
[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 rea
Paul Moore wrote:
> I'm not sure I agree with that - to me, PEP 340 felt like the
> consolidation of the previous discussion. My feeling was "cool - we've
> had the discussion, now we've formalised the results, maybe a few
> details to tidy up and then we can see the implementation being
> checked
Guido van Rossum wrote:
> [Nick Coghlan]
>
>>>http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> I have the same question for Nick. Interestingly, assuming Nick meant
> that "raise" to be there, PEP 3XX and PEP 343 now have the same
> translation. In rev 1.10 I moved the __enter__ call o
Nick Coghlan wrote:
> 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 abou
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
> implement
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 o
Phillip J. Eby wrote:
> At 08:18 AM 5/16/2005 +1000, Nick Coghlan wrote:
>
>> 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 beha
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 non-backwards-com
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,
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
various backwards-compatibility constraints.
E
Nick Coghlan wrote:
> The naming convention for 'do' is shown in the current PEP 343. The issue
> I've
> noticed with it is that *functions* read well, but methods don't because
> things
> get out of sequence. That is, "do locking(the_lock)" reads well, but "do
> the_lock.locking()" does not.
Guido van Rossum wrote:
> But then the reason for separating VAR from EXPR becomes unclear.
> Several people have mentioned that they thought this was "a good idea
> on its own", but without giving additional use cases. Without the
> ability to write the acquire/release template as a generator, th
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 other cases are where you want to do something in response to an
exception, but not otherwise::
def gen():
try:
yie
On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
In reading over PEP 3XX again, it struck me that I'd been having a
really hard time grasping exactly when I needed to use the
"needs_finish" decorator. Am I right in saying that I shoul
On Sun, 15 May 2005, Guido van Rossum wrote:
> 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__.
No, it wasn't insane. You h
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.
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
t
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 th
Phillip J. Eby wrote:
> This makes it seem awkward for e.g. "do self.__lock", which doesn't
> make any sense. But the extra call needed to make it "do
> locking(self.__lock)" seems sort of gratuitous.
How about
do holding(self.__lock):
...
> It makes me wonder if "with" or "using" or
Guido van Rossum wrote:
> [...] But some of the claims from PEP 3XX seem to be incorrect now: Nick
> claims that a with-statement can abstract an except clause, but that's
> not the case; [...]
Sorry for being a lurker, but can I try and expand this point.
The options:
- If we don't allow the ex
It's been interesting watching all the loops this discussion has gone
through. I'm not sure the following is compatible with the current
proposals, but maybe it will spur some ideas or help rule out something.
There have been several examples of problems with opening several
resources inside
Ka-Ping Yee wrote:
> 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 V
At 08:18 AM 5/16/2005 +1000, Nick Coghlan wrote:
>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
[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
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> 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 P
Shane Hathaway wrote:
> PEP 340 is very nice, but it became less appealing to me when I saw
> what it would do to "break" and "continue" statements.
Absolutely. I really liked PEP 340, but two things stood out to me as
being flawed:
1. Looping - it took a while for me to realise this was buggin
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():
>
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
Steven Bethard wrote:
> On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>
>
>>From there I see the semantics:
>
> VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
> exc = (None, None, None)
> try:
> try:
> BLOCK1
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.
Havi
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
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
On 5/15/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
>From 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()
fin
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.
Agr
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()
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
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 that occur into the template generator's inte
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.
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-
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-
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
[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
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:
[Nick Coghlan]
> Maybe PEP 343 should drop any suggestion of using generators to define these
> things, and focus on the PEP 310 style templates.
But then the reason for separating VAR from EXPR becomes unclear.
Several people have mentioned that they thought this was "a good idea
on its own", but
[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 translation) whose __enter
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 mai
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 t
Nick Coghlan wrote:
> I think the key benefit relates to the fact that correctly written resource
> management code currently has to be split it into two pieces - the first piece
> before the try block (e.g. 'lock.acquire()', 'f = open()'), and the latter in
> the finally clause (e.g. 'lock.releas
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 benefi
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
>
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
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
[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
>
[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
>
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
At 05:13 PM 5/13/2005 -0700, 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 t
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 positive responses there.
Plea
80 matches
Mail list logo
