[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
[Jack Diederich]
> I prefer trichomomies over dichotomies, but whether single or double
> underscores are "the bad" or "the ugly" I'll leave to others. In python
> double underscores can only mean "I don't handle this, my class does" or
> "I'm a C++ weenie, can I pretend this is private?"
>
> Excl
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
On Mon, May 16, 2005 at 10:11:47PM -0400, Jack Diederich wrote:
> The values are never shared by expections of the class
^^
s/expect/except/
Exceptions are expected by except statements - and ispell can't tell the
difference.
-jackdied
___
On Mon, May 16, 2005 at 08:09:54PM -0500, Ka-Ping Yee wrote:
> On Mon, 16 May 2005, Aahz wrote:
> > I'll comment here in hopes of staving off responses from multiple
> > people: I don't think these should be double-underscore attributes. The
> > currently undocumented ``args`` attribute isn't doub
On Mon, 16 May 2005, Aahz wrote:
> I'll comment here in hopes of staving off responses from multiple
> people: I don't think these should be double-underscore attributes. The
> currently undocumented ``args`` attribute isn't double-underscore, and I
> think that's precedent to be followed.
That i
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
Guido van Rossum wrote:
[SNIP - bunch of points from Guido]
> Do we really need both __context__ and __cause__? Methinks that you
> only ever need one: either you explicitly chain a new exception to a
> cause, and then the context is probably the same or irrelevant, or you
> don't explicitly chain
[Ka-Ping Yee]
> This PEP is a concrete proposal for exception chaining, to follow
> up on its mention here on Python-Dev last week as well as earlier
> discussions in the past year or two.
>
> http://www.python.org/peps/pep-0344.html
Here's a bunch of commentary:
You're not giving enough cre
David M. Wilson wrote:
> Before charging on ahead with this small task, I was wondering if anyone
> would have any objections to such an upgrade. It seems to me that
> itertools.chain() could come in handy there, at least.
>
> My only objection to the current implementation is that it doesn't
>
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
On Mon, May 16, 2005, Ka-Ping Yee wrote:
>
> This PEP is a concrete proposal for exception chaining, to follow
> up on its mention here on Python-Dev last week as well as earlier
> discussions in the past year or two.
>
> http://www.python.org/peps/pep-0344.html
>
> I've tried to summarize th
This PEP is a concrete proposal for exception chaining, to follow
up on its mention here on Python-Dev last week as well as earlier
discussions in the past year or two.
http://www.python.org/peps/pep-0344.html
I've tried to summarize the applications for chaining mentioned in
these discussion
Hi there,
Before charging on ahead with this small task, I was wondering if anyone
would have any objections to such an upgrade. It seems to me that
itertools.chain() could come in handy there, at least.
My only objection to the current implementation is that it doesn't
reflect the current Pyt
At 11:20 AM 5/16/2005 -0700, Guido van Rossum wrote:
>I think the issue here is not implementation details but whether it
>follows a certain protocol. IMO it's totally acceptable to require
>that the expression used in a with-statement support an appropriate
>protocol, just like we require the expr
[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
Nick's PEP 3XX is here:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
[Phillip J. Eby]
> Anyway, I took a look at it, and I mostly like it.
I like the beginning of Nick's PEP too, since its spec for the with
statement is now identical to PEP 343 apart from the keyword choice
(and I'm
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)
At 06:56 PM 5/16/2005 +1000, Nick Coghlan wrote:
>Anyway, I think it's stable enough now that I can submit it to be put up on
>www.python.org (I'll notify the PEP editors directly once I fix a couple of
>errors in the current version - like the missing 'raise' in the statement
>semantics. . .).
If
[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
On Mon, May 16, 2005, Greg Ewing wrote:
> Aahz wrote:
>> On Fri, May 13, 2005, Greg Ewing wrote:
>>>
>>>Instead of an 'args' attribute, I'd suggest that the constructor take
>>>keyword arguments and store them in corresponding attributes.
>>
>> Sounds reasonable, but it should be equally easy to h
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
"Chris Ryland" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I hate to add to what could be an endless discussion, but... ;-)
>
> In this case, "while" is the better time-related prefix, whether
> keyword (hopeless, due to ages-old boolean-controlled loop association)
> or functi
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
Aahz wrote:
> On Fri, May 13, 2005, Greg Ewing wrote:
>
>>Instead of an 'args' attribute, I'd suggest that the constructor take
>>keyword arguments and store them in corresponding attributes.
>
> Sounds reasonable, but it should be equally easy to handle::
>
> raise MyError, "message"
Certai
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
36 matches
Mail list logo
