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
I have finished up the hashlib work I started on in feb/march for
patch 1121611 and 935454 after some discussion on this list. The full
patch including tests and module documentation has been posted in the
sf patch 1121611 as hashlib-008.
I believe it is done and ready and would like to commit it
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
> "Gustavo" == Gustavo Niemeyer <[EMAIL PROTECTED]> writes:
Gustavo> An issue to consider about this is that maintainers (not
Gustavo> talking about you or anyone else specifically) have
Gustavo> different concepts of stability, and while it may seem
Gustavo> perfectly ok to re
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
On Fri, Jun 10, 2005 at 01:13:35PM -0500, Jeff Epler wrote:
> > Is this a feature? I do see b32encode padding the string with NULs first.
This is bug #1170331, which was fixed when I applied patch #1171487
earlier this week.
> This also seems suspect:
> >>> base64.b32encode("\0a")
> 'ABQQ'
>
15 matches
Mail list logo
