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
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 thought it was
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
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' attribute set to
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
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 objects
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
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 be a runtime
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
-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 list
18 matches
Mail list logo
