On Sun, 2005-06-12 at 00:52, Nick Coghlan wrote:
> The idea behind 'with' is that the block is executed while holding
> (i.e. 'with') the resource.
>
> I think the '-ing' form of the example templates is a holdover from
> the days when the PEP used the 'do' keyword - I find that past tense
> o
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 hal
> > 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
At 10:40 PM 6/13/2005 +1000, Nick Coghlan wrote:
>Hmm, you're right. Also, given implementation of PEP 343, code which
>genuinely has to care about this can do so manually:
>
>with async_exceptions_blocked():
>with critical_resource():
>with async_exceptions_unblocked():
>
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 tr
[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 P
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 object
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 doub
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 Canterbu
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 ca
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 ca
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
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 __en
Nick Coghlan wrote:
> Either way, the code generation for the with statement could simply
> emit BLOCK_ASYNC as the first opcode, then ALLOW_ASYNC as the opcode
> immediate preceding SETUP_FINALLY. Correct behaviour in the face of
> asynchronous events is then guaranteed, even for cases where th
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 would be necessary to
s
Guido van Rossum wrote:
>>It also considers the possibility of using with statements in an RAII
>>style by acquiring the resource in __init__ or __new__ rather than
>>__enter__.
>
>
> Python isn't C++; you shouldn't do that.
>
>
>>This is a topic that got a brief mention during early discussion
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
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, i
[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 ac
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 inje
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
> # ...
"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
> 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
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], EX
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
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], EX
> - 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
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 t
28 matches
Mail list logo
