Raymond Add untokenize() function to allow full round-trip tokenization.
Raymond Should significantly enhance the utility of the module by
Raymond supporting the creation of tools that modify the token stream
Raymond and writeback the modified result.
Raymond,
Very interesting.
Greetings,
It seems like a good idea to have another Python bug day. Saturday
June 25th seems the most practical date (this coming weekend is too
soon, and the weekend after is a minor holiday -- Father's Day).
We'd convene in the usual place: the #pydotorg IRC channel, on
moving the main trunk and main development over to the Python CVS is
another thing, entirely.
(as I've said many times before, both the user community and the developer
community would benefit if the core standard library were made smaller, and
more externally maintained packages were
On Fri, Jun 10, 2005 at 11:35:47AM -0300, Gustavo Niemeyer wrote:
Not sure if that's a reason to prevent the event, since
fixing bugs is a good thing no matter when, but that's two
days before EuroPython, and many people might be moving to
the conference at that time.
Thanks for pointing that
Recently, I reviewed the following five patches:
[ 827386 ] absolute paths cause problems for MSVC
[ 1161914 ] python-config
[ 1187396 ] Add const specifier to PySpam_System prototype
[ 1196895 ] in IDLE, assume new text files are python source by default
[ 1196917 ] change recall in IDLE shell
Michiel De Hoon [EMAIL PROTECTED] writes:
I'd like to ask your attention to this patch:
[ 1049855 ] PyOS_InputHook inconsistency on Windows
Kurt Kaiser has already looked at this patch, but was hesitant to check it in
because he wasn't able to test it on Windows. I'd be happy to send a
On Tue, Jun 07, 2005 at 08:23:18PM -0700, Pavel Pergamenshchik wrote:
Hi.
Is this a feature? I do see b32encode padding the string with NULs first.
b32decode(b32encode('\x00'))
Traceback (most recent call last):
File stdin, line 1, in ?
File /usr/lib/python2.4/base64.py, line 228, in
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
13 matches
Mail list logo
