Phillip J. Eby wrote:
Ow. My head hurts. :) Seriously, though, wouldn't it make more sense
to put the 'with async_exceptions_blocked()' in the __init__ or
__enter__ of 'critical_resource'? Or am I still missing something?
Heck, I *suggested* the trick, and still had to look at it a half
Guido van Rossum wrote:
We considered this at some point during the PEP 340/343/346 discussion
(in fact I had it this way in an early version of one of the PEPs),
and in the end decided against it. I believe the argument was that any
failure *before* __enter__() returns can be handled by
But I cannot do this:
def f(x as (a, b)):
# ...
which is what I was suggesting.
Yeah, I knew that. How important is that to you?
I would really have liked it for a program I was working on at one time that
had lots of small methods that passed around values of forms
I can't make time for this right now, but the more I think about it,
the more I believe the worry about asynchronous exceptions is mostly
irrational. Despite your proof that it *can* be implemented I really
don't want to see anything like that implemented -- I doubt that
you've covered all the
Nick Coghlan [EMAIL PROTECTED] writes:
It also considers the possibility of using with statements in an RAII
style by acquiring the resource in __init__ or __new__ rather than
__enter__.
While you can probably do this (after all, most of the time
__new__/__init__ and __enter__ will be called
Guido van Rossum wrote:
So (a) would have my preference.
Mine, too.
the PEP would have to be amended to state that
VAR must be a single variable or a list of variables IN PARENTHESES.
+1
--
Greg Ewing, Computer Science Dept, +--+
University of
Guido van Rossum wrote:
I can't make time for this right now, but the more I think about it,
the more I believe the worry about asynchronous exceptions is mostly
irrational. Despite your proof that it *can* be implemented I really
don't want to see anything like that implemented -- I doubt
Michael Hudson wrote:
While you can probably do this (after all, most of the time
__new__/__init__ and __enter__ will be called in rapid succession) I
really think the RAII meme doesn't apply to Python; you generally want
a resource to be acquired for a period of definite extent, and objects
[Nick]
As I just added to the Wiki, dropping the issue completely works for
me. I'm also far from convinced I'd covered all the corner cases
(besides, blocking KeyboardInterrupt for an arbitrary amount of time
made me uncomfortable).
OK.
You'd mostly convinced me that RAII was rare in
The issue is: if we allow VAR to be a
comma-separated list of variables now, that cuts off the extension to
(a) in the future; so the PEP would have to be amended to state that
VAR must be a single variable or a list of variables IN PARENTHESES.
Thoughts?
I am not sure how relevant this is,
Andrew Koenig [EMAIL PROTECTED] wrote:
Of course, this usage shows that the syntax is unnecessary in this context,
but what I care about is
def f(x as (a, b)):
# ...
which has the advantage over the alternative
def f(x):
(a, b) = x
Andrew Koenig wrote:
Of course, this usage shows that the syntax is unnecessary in this context,
but what I care about is
def f(x as (a, b)):
# ...
which has the advantage over the alternative
def f(x):
(a, b) = x
# ...
that if
Guido van Rossum wrote:
While there's still some activity in the Wiki, nothing (to me) sounds
like signs of serious disagreement or truly better alternatives. So I
think I'd like to move forward towards acceptance soon (before
EuroPython).
I agree with keeping throw() as the exception
[Nick]
I also added a new question to the Wiki regarding what, if any,
guarantees will be made regarding when (or if) asynchronous interrupts
will be blocked. Given that the call to __enter__() can invoke
arbitrary Python code, is pushing the with statement setup inside a
single opcode
At 09:02 AM 6/11/2005 -0700, Guido van Rossum wrote:
[Nick]
I also added a new question to the Wiki regarding what, if any,
guarantees will be made regarding when (or if) asynchronous interrupts
will be blocked. Given that the call to __enter__() can invoke
arbitrary Python code, is
On Fri, 2005-06-10 at 16:23, Guido van Rossum wrote:
While there's still some activity in the Wiki, nothing (to me) sounds
like signs of serious disagreement or truly better alternatives. So I
think I'd like to move forward towards acceptance soon (before
EuroPython).
Well, I finally read PEP
Nick Coghlan wrote:
Nick Coghlan wrote:
Then all the two new opcodes (e.g. ALLOW_ASYNC, BLOCK_ASYNC) would
have to do is set the state of tstate-allow_async_exc appropriately.
Actually, to allow the use of 'with' statements inside functions
called via EXPR and the call to __enter__, it
Barry Warsaw wrote:
On Fri, 2005-06-10 at 16:23, Guido van Rossum wrote:
While there's still some activity in the Wiki, nothing (to me) sounds
like signs of serious disagreement or truly better alternatives. So I
think I'd like to move forward towards acceptance soon (before
EuroPython).
While there's still some activity in the Wiki, nothing (to me) sounds
like signs of serious disagreement or truly better alternatives. So I
think I'd like to move forward towards acceptance soon (before
EuroPython).
Two issues brought up in the Wiki are worth considering:
- throw() is a term
At 01:23 PM 6/10/2005 -0700, Guido van Rossum wrote:
- throw() is a term taken from Java C++. We can't call the method
raise() -- but perhaps we can call it next_raising() or next_raise(),
which emphasizes the similarity with next(). Thoughts? I'm not strong
on this; I think throw() is fine too,
- throw() is a term taken from Java C++.
This was intended. There was much discussion about this for PEP 288 and
this was more or less a concensus choice. The term is already
associated with exceptions in other languages and it captures the
concept of the raise occurring somewhere else (what
In article [EMAIL PROTECTED],
Guido van Rossum [EMAIL PROTECTED] wrote:
...
- Whether and how to keep a door open for a future extension to the
syntax that allows multiple resources to be acquired in a single
with-statement. Possible syntax could be
(a)with EXPR1 [as VAR1], EXPR2 [as
On 6/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
- throw() is a term taken from Java C++.
This was intended. There was much discussion about this for PEP 288 and
this was more or less a concensus choice. The term is already
associated with exceptions in other languages and it
Guido van Rossum wrote:
[SNIP - Guido already said throw() is the name to be used]
- Whether and how to keep a door open for a future extension to the
syntax that allows multiple resources to be acquired in a single
with-statement. Possible syntax could be
(a)with EXPR1 [as VAR1], EXPR2
24 matches
Mail list logo
