Re: [Python-Dev] [Python-checkins] python/dist/src/Doc/lib libtokenize.tex, 1.5, 1.6
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. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug day on the 25th?
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 > irc.freenode.net. > > Assuming no one can think of a reason why the 25th would be > unsuitable, I'll send an announcement to c.l.py.a in a few days. 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. -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on stdlib evolvement
> > 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 included in the standard releases) An issue to consider about this is that maintainers (not talking about you or anyone else specifically) have different concepts of stability, and while it may seem perfectly ok to refactor external modules between two stable releases, doing so in the standard library would spread fear and "python is so untrustful" feelings. That's something a good police, reflecting practices that we learn "by osmose" while living in that environment (python-dev) for a while, could try to handle. Enforcing it is another issue, of course. -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug day on the 25th?
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 out. It'll probably mean that most of the participants will be North Americans. The next available weekend would be July 9th, though, so I think we should go ahead with the bug day on the 25th. I'll try to have another one in July, too. Maybe we should adopt a standard day for bug days, e.g. second Saturday of the month, or something like that. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Five patch reviews & patch request
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 to not overwrite current command Below are the summaries of the patch reviews. 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 compiled Python for Windows to anybody willing to have a look at this patch. Thanks! --Michiel. Patch review summaries: --- [ 827386 ] absolute paths cause problems for MSVC Solves an inconsistency between distutils' msvccompiler.py and ccompiler.py. I am surprised by how absolute paths are handled in ccompiler.py, so I'm not wholeheartedly in favor of copying this behavior to msvccompiler.py. [ 1161914 ] python-config Currently, the patch seems to be broken. Better integration with distutils is needed. Can't recommend this patch in its current form. [ 1187396 ] Add const specifier to PySpam_System prototype This error is already fixed in Revision 1.33 of python/dist/src/Doc/ext/extending.tex. Patch can be closed. [ 1196895 ] in IDLE, assume new text files are python source by default When going to File > New in IDLE, currently IDLE assumes that the new file is a generic text file. With the patch, IDLE assumes that the new file contains python source code by default, and uses syntax highlighting. Whereas currently syntax highlighting is switched on as soon as the file is saved as *.py, after the patch syntax highlighting is not switched off if the file is saved as *.txt. So the patch does not seem to be perfectly OK. [ 1196917 ] change recall in IDLE shell to not overwrite current command I agree that this patch makes IDLE easier to use. Recommend applying this patch. Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Five patch reviews & patch request
"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 compiled > Python for Windows to anybody willing to have a look at this patch. Comment about the patch (only from reading it): The PyOS_StdioReadline function calls my_fgets with a file pointer argument. The my_fgets function in the patch assumes that STD_INPUT_HANDLE is the handle to use - is this assumption always correct? Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] b32encode and NUL bytes
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 "", line 1, in ?
> File "/usr/lib/python2.4/base64.py", line 228, in b32decode
> last = binascii.unhexlify(hex(acc)[2:-1])
> TypeError: Odd-length string
This also seems suspect:
>>> base64.b32encode("\0a")
'ABQQ'
>>> base64.b32decode(_)
'a'
Jeff
pgpYoIR86pYL4.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 343 - next steps
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 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. - 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, ...: Variant (a) seems better and is more analogous to the use of 'as' in import statements, and (b) has the disadvantage that if you want to acquire several resources and not all of them have an associated variable, you'll have to sprinkle dummy variables on the right of 'as'. So (a) would have my preference. But I would still like to start off without this extension. 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? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 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, especially since I expect that >it will be used explicitly extremely rarely -- the only customer is >the with_template decorator. I'm fine with throw, but if you really want to get 'raise' in there, how about 'raise_exc' or 'raise_exc_info'? >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? Parentheses would make it clearer what's going on, so I'd be fine with that. ___ Python-Dev mailing list [email protected] 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
> - 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 is thrown at or into). It is simple, clear, and tends to suggest all the right things. I have no doubt that someone can point out differing semantics in other languages but I don't care. The verbal cue is what we are after. Raymond ___ Python-Dev mailing list [email protected] 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
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 VAR2], EXPR3 [as VAR3], ...: > > or > > (b)with EXPR1, EXPR2, EXPR3, ... as VAR1, VAR2, VAR3, ...: > > Variant (a) seems better and is more analogous to the use of 'as' in > import statements, and (b) has the disadvantage that if you want to > acquire several resources and not all of them have an associated > variable, you'll have to sprinkle dummy variables on the right of > 'as'. So (a) would have my preference. But I would still like to start > off without this extension. 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 agree that (a) sounds better. Also, I think it is very reasonable to require that multiple variables be in parenthesis. You can always lift the restriction later (i.e. if enough folks complain and you decide never to implement (a)), but you can't add such a restriction later. One nit-pick: I suggest not using the term "list of in parenthesis" in the PEP or other docs. It's clear here but may add to some people's list vs tuple confusion. -- Russell ___ Python-Dev mailing list [email protected] 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 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 captures the > concept of the raise occurring somewhere else (what is thrown at or > into). It is simple, clear, and tends to suggest all the right things. > > I have no doubt that someone can point out differing semantics in other > languages but I don't care. The verbal cue is what we are after. Cool. throw() it is. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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: [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 [as VAR2], EXPR3 [as VAR3], ...: > > or > > (b)with EXPR1, EXPR2, EXPR3, ... as VAR1, VAR2, VAR3, ...: > > Variant (a) seems better and is more analogous to the use of 'as' in > import statements, and (b) has the disadvantage that if you want to > acquire several resources and not all of them have an associated > variable, you'll have to sprinkle dummy variables on the right of > 'as'. So (a) would have my preference. But I would still like to start > off without this extension. 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 like a), so I say restrict the grammar as needed to allow it become a possibility. Forcing parens is a minor thing and since this is not syntactically the same as assignment the difference is negligible. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
