Yikes, this turned out to be rather long. Here's a summary:
- The expansion suggested by Shane (moving __enter__ outside the
try-finally) fits the expectation that __exit__ will always be
paired with a successful __enter__. This "paired-exit" expansion
is fairly intuitive and makes
> -was, under the covers, a (optential) looping construct. This
> +was, under the covers, a (potential) looping construct. This
I'm glad I didn't fix this one.
I thought he meant to use "optional".
Raymond Hettinger
___
Python-Dev mailing lis
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-
On May 14, 2005, at 3:05 PM, Shane Hathaway wrote:
> M.-A. Lemburg wrote:
>
>> It is important to be able to rely on a default that
>> is used when no special options are given. The decision
>> to use UCS2 or UCS4 is much too important to be
>> left to a configure script.
>>
>
> Should the choice
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
On May 14, 2005, at 2:34 PM, Aahz wrote:
> On Fri, May 13, 2005, Greg Ewing wrote:
>
> Sounds reasonable, but it should be equally easy to handle::
>
> raise MyError, "message"
Make that:
raise MyError("message")
There's really no reason for a multi-argument raise when exceptions
are ob
M.-A. Lemburg wrote:
> It is important to be able to rely on a default that
> is used when no special options are given. The decision
> to use UCS2 or UCS4 is much too important to be
> left to a configure script.
Should the choice be a runtime decision? I think it should be. That
could mean two
Guido van Rossum wrote:
> [Brett C.]
>
>>Maybe, but as long as caught exceptions get cleared that should be an issue.
>>Would this be solved if, when an 'except' branch is exited, exceptions are
>>cleared? So, in the above example, once the 'pass' is hit in catchit() no
>>exception is considered
On Fri, May 13, 2005, Greg Ewing wrote:
> Brett C. wrote:
>>
>> Seems like, especially if we require inheritance from a base
>> exception class in Python 3000, exceptions should have standard 'arg'
>> and 'traceback' attributes with a possible 'context' attribute (or
>> always a 'context' attribut
[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
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Michael Hudson, after much thinking aloud]
Yeah, sorry about that :)
>> Oh, I guess the point is that with a decorated generator you can yield
>> a value to be used as VAR, rather than just discarding the value as
>> here. Hmm.
>
> Right. (I thoug
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
>
23 matches
Mail list logo
