Re: [Python-Dev] b32encode and NUL bytes
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' base64.b32decode(_) 'a' This case is also fixed in CVS. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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, but the syntax x as (a, b) sure looks to me like (a, b) is a tuple. Of course, I'm biased by ML, which has a feature that I wish Python had: fun f(x as (a, b)) = ... This says that f's argument must be a 2-element tuple. It binds x to the argument and also binds a and b to the argument's components. Of course the program could be written this way: fun f(x) = let val (a, b) = x in ... end but the as syntax is more succinct, direct, and convenient. If such a feature were implemented in Python, I would imagine it to allow usages such as x as (a, b) = (3, 4) which would be equivalent to x = (a, b) = (3, 4) 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 you call f with the wrong arguments, you get a clearer diagnostic message. It's kind of an edge case, and I am not seriously pushing for its adoption, but I do think it worth pointing out that when I see x as (a, b), that's what it immediately brings to mind. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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 # ... that if you call f with the wrong arguments, you get a clearer diagnostic message. Thanks to the time machine, you can already do this: def f((a, b)): # ... -- Christian Tanzerhttp://www.c-tanzer.at/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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 you call f with the wrong arguments, you get a clearer diagnostic message. Doesn't tuple unpacking give you what you want here already? Py def f((a, b)): ... print a, b ... Py f(1, 2) Traceback (most recent call last): File stdin, line 1, in ? TypeError: f() takes exactly 1 argument (2 given) Py f((1, 2)) 1 2 A couple of more complex examples: Py def f((a, b), (c, d)): ... print a, b, c, d ... Py f((1, 2), (3, 4)) 1 2 3 4 Py def f((a, b, (c, d))): ... print a, b, c, d ... Py f((1, 2, (3, 4))) 1 2 3 4 About the only downside is the need to rebuild the tuple if you actually need it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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 injection method name, and the addition of required parentheses when using tuple unpacking when creating VAR. 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 actually sufficient? It also considers the possibility of using with statements in an RAII style by acquiring the resource in __init__ or __new__ rather than __enter__. This is a topic that got a brief mention during early discussion here, but doesn't seem to be covered in the current version of PEP 343. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
[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 actually sufficient? Not sufficient if __enter__ is written in Python; in that case, *nothing* can be done to make it sufficient. The single opcode makes it possible to implement __enter__ in C to solve the issue in specific cases. 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 here, but doesn't seem to be covered in the current version of PEP 343. I haven't been infected with the RAII meme, so I can't help you here. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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 pushing the with statement setup inside a
single opcode actually sufficient?
Not sufficient if __enter__ is written in Python; in that case,
*nothing* can be done to make it sufficient.
I think PEP 343 would greatly benefit from some discussion of the
signalling issue. I've been wracking my brain a bit on it, and I'm having
trouble seeing where the problem is.
The single opcode makes it possible to implement __enter__ in C to
solve the issue in specific cases.
Or if __enter__ is a no-op, that would also solve the problem. Suitability
for 'with' could be keyed off of the __exit__ method instead. If there's
no __enter__, or the __enter__ is a default no-op __enter__ written in C,
then __exit__ is sufficient for many resources.
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.
Actually, it seems to me that it's standard procedure in today's Python:
objects allocate resources in __init__, and then have a 'close()' or some
similar method to release them. That's why so many people see this:
with open('foo') as f:
...
As a natural use of the 'with' statement, whether they have any familiarity
with C++ or not. (My own experiences with C++ are perhaps a decade out of
date, long before RAII was a meme in any event.)
It seems to me that there are two sensible patterns for using 'with':
1. __enter__ allocates or acquires a resource, __exit__ releases it
2. EXPR allocates or acquires a resource, __exit__ releases it (and
__enter__ doesn't execute any Python, because it's a no-op)
Pattern 1 is useful for transactions, locks, redirection, decimal contexts,
etc.
Pattern 2 is useful for resources that are acquired by creation anyway,
like files.
But maybe my understanding is flawed, because I don't *really* understand
the signal issue. I've been assuming that you're talking about the fact
that an exception can occur anywhere, due to e.g. KeyboardInterrupt or an
exception raised by some other signal handler. It seems to me that using
pattern 2, one could write 'closing()' safely
by doing this:
class closing(object):
def __init__(self, resource):
try:
self.resource = resource
except:
resource.close()
raise
def __exit__(self,*exc):
self.resource.close()
but maybe I'm still fundamentally not getting how the signal issue
manifests in practice. I suppose it's true that *another* exception could
then occur between the LOAD_ATTR and the CALL opcodes in the exception
handler here, but it's also true that this could happen with any Python
exception-handling code, and it could also happen in __exit__(). So I'm
not sure I see why this should influence the design of 'with' very much,
other than to point out that no Python code is safe from asynchronous
exceptions.
In any case, C-implemented types can handle this situation just fine, so a
'closing' written in C could easily be included with the implementation.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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 343 in its entirety. Having not really had the time to follow this thread, I have to say well done. I like the PEP a lot and can see many places in my own code where it would make things more readable. I have one comment, and I may be too late or may be repeating other suggestions (no, I haven't poured through the wiki page yet). I actually don't think with reads as well and would propose when. The word I'd really like to use here is while but given that we already have while loops and as is optional, I don't think that's a possibility. If you made as required, it would be though, I think. Look at the given examples: with locking(mylock): when locking(mylock): with opening(/etc/passwd) as f: when opening(/etc/passwd) as f: with opening(filename, w) as f: with redirecting_stdout(f): print Hello world when opening(filename, w) as f: when redirecting_stdout(f): print Hello world with signal_blocking(): when signal_blocking(): - 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, especially since I expect that it will be used explicitly extremely rarely -- the only customer is the with_template decorator. As others have mentioned throw() is fine. - 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 VAR2], EXPR3 [as VAR3], ...: or (b)with EXPR1, EXPR2, EXPR3, ... as VAR1, VAR2, VAR3, ...: I agree that (a) is better and feel +1 on keeping the door open to it. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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 would be necessary to support nesting of calls to BLOCK_ASYNC and ALLOW_ASYNC, so a better approach would be to make the field tstate-block_async_exc, incrementing it in BLOCK_ASYNC, and decrementing it in ALLOW_ASYNC. And, replying to myself yet again. . . Such an approach would obviously break in the face of an exception that occurs between the BLOCK_ASYNC and ALLOW_ASYNC opcodes (async exceptions would remain blocked in the thread). This can be dealt with by storing the question of whether or not async exceptions are permitted as part of the *frame* state, rather than the thread state. That is, make the field access be f-allow_async_events, and have ALLOW_ASYNC and BLOCK_ASYNC set or clear that flag, respectively. The error handling code after the main opcode switch statement can then simply set f-allow_async_exc back to true in order to ensure that handling of async exceptions is resumed correctly in the event of try/finally or try/except blocks causing further execution within the frame. (Given that only expressions are possible on the resource acquisition line, dealing with the WHY_EXPRESSION case seems to be all that would be needed). Regards, Nick. P.S. My suggested semantics and the above implementation outline should be up on the Wiki shortly. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - next steps
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). Well, I finally read PEP 343 in its entirety. Having not really had the time to follow this thread, I have to say well done. I like the PEP a lot and can see many places in my own code where it would make things more readable. I have one comment, and I may be too late or may be repeating other suggestions (no, I haven't poured through the wiki page yet). I actually don't think with reads as well and would propose when. 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 or noun forms tend to read better than present tense for custom built with templates named after the action that occurs on entry: # Past tense with locked(my_lock): with opened(my_file, mode): with redirected_stdout(my_stream): # Noun forms with my_lock: with open(my_file, mode) as f: with extra_precision(): with decimal.getcontext() as ctx: The place where the '-ing' form still makes some sense is when the template is named after the action that will occur at the *end* of the block: with closing(some_gen()) as g: with releasing(some_rsrc()) as r: Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
