Mailman 3 February 2005 - Python-Dev

Patch review [ 981773 ] crach link c++ extension by mingw
by Michiel Jan Laurens de Hoon Feb. 8, 2005

Feb. 8, 2005

Patch review [ 981773 ] crach link c++ extension by mingw When building a C++ extension for Windows using MinGW, the linking would fail due to an incorrect link command. The patch contains a solution for this problem. I could reproduce this bug with Python 2.3.5c1, but in Python 2.4 it seems to have been fixed. Using this Python version: '2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)]' a C++ extension compiled and linked correctly with MinGW. So I think this patch is no longer needed (except if we want to back-port it to 2.3.5, which I doubt). --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

1 0

BRANCH FREEZE for 2.3.5
by Anthony Baxter Feb. 8, 2005

Feb. 8, 2005

Can people stay off the release23-maint branch while we cut 2.3.5 (final), starting in about 5 hours time (say, around 1200 UTC). Thanks, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: python/dist/src/Lib DocXMLRPCServer.py, 1.4, 1.5 cookielib.py, 1.6, 1.7 copy.py, 1.43, 1.44 optparse.py, 1.12, 1.13 pickle.py, 1.160, 1.161 subprocess.py, 1.13, 1.14 unittest.py, 1.37, 1.38 xmlrpclib.py, 1.36, 1.37
by Fredrik Lundh Feb. 7, 2005

Feb. 7, 2005

> Reduce the usage of the types module. > Index: xmlrpclib.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/xmlrpclib.py,v # Notes: # this version is designed to work with Python 2.1 or newer. > - dispatch[IntType] = dump_int > + dispatch[int] = dump_int $ python2.1 >>> type(0) == int 0 >>> type([]) == list 0 >>> type({}) == dict Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'dict' is not defined </F>

1 0

Other library updates
by Raymond Hettinger Feb. 7, 2005

Feb. 7, 2005

Any objections to replacing the likes of types.IntType and types.ListType with int and list? Raymond

3 2

RE: [Python-checkins] python/dist/src/Lib/test test_copy.py, 1.11.8.1, 1.11.8.2
by Raymond Hettinger Feb. 7, 2005

Feb. 7, 2005

> Modified Files: > Tag: release23-maint > test_copy.py > Log Message: > fix bug 1114776 Don't forget release24-maint. Raymond

2 1

list of constants -> tuple of constants
by Skip Montanaro Feb. 6, 2005

Feb. 6, 2005

In a python-checkins message, Raymond stated: Raymond> Replace list of constants with tuples of constants. I understand the motivation here (the peephole optimizer can convert a tuple of constants into a single constant that need not be constructed over and over), but is the effort worth the cost of changing the logical nature of the data structures used? If lists are conceptually like vectors or arrays in other languages and tuples are like C structs or Pascal records, then by converting from list to tuple form you've somehow muddied the data structure water just to take advantage of tuples' immutability. Wouldn't it be better to have the peephole optimizer recognize the throwaway nature of lists in these contexts: for elt in [1, 2, 4, 8, 16]: ... if foo in [list, tuple]: ... (anywhere a list of constants immediately follows the "in" or "not in" keywords) and convert them into constants? The cases you converted all matched that usage. Skip

4 5

Wanted: members for Python Security Response Team
by Guido van Rossum Feb. 6, 2005

Feb. 6, 2005

If you read BugTraq, python-announce or the Daily Python URL today, you would have noticed a Python Security Advisory. (If you missed it: http://www.python.org/security/PSF-2005-001/ .) This was the first one issued in this form, but I'm sure it won't be the last one. Until now, we haven't had any infrastructure for this type of thing. In this particular case, the original discoverer first asked on c.l.py for advice on how to proceed, which yielded only unhelpful referrals to SF or python-dev. Then he wrote the authors of the affected module. Fredrik was so kind to forward it to me, and I happened to have time to deal with it. (Hey, I work for a security company, so I would have *made* time if I had to.) But I may not always be that responsive -- I could be busy, or traveling, or people might not think of mailing me. I believe it would be better if there was a "response team" for such situations. The response team would normally not have to do anything; they wouldn't have to be actively looking for security bugs, for example. But anyone with a (suspected) security problem related to Python would be able to email the team (e.g. security at python.org), trusting that the information would be kept confidential until a patch is developed; the response team would then investigate the problem and decide on an appropriate response. I want to be on the team; Barry also works for a security company and I hope he'll want to join (he can also make up a better acronym :-); I hope at least one person from the release team can be involved, e.g. Anthony; and I would like to see some more volunteers involved to have a good spread of availability and expertise. (How about a Windows user?) If you want to be on the team, send email to me *personally*. For discussion about the team's responsibilities and procedures, please follow up here. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

6 8

Re: [Python-checkins] python/dist/src/Python future.c, 2.14, 2.15
by Anthony Baxter Feb. 5, 2005

Feb. 5, 2005

On Saturday 05 February 2005 05:38, jhylton(a)users.sourceforge.net wrote: > Fix bug that allowed future statements virtually anywhere in a module. > > If we exit via the break here, we need to set ff_last_lineno or > FUTURE_POSSIBLE() will remain true. The bug affected statements > containing a variety of expressions, but not all expressions. It has > been present since Python 2.2. While this is undoubtedly a bug fix, I'm not sure that it should be backported - it will break people's code that is "working" now (albeit in a faulty way). What do people think? -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

4 3

cookielib patch
by John J Lee Feb. 4, 2005

Feb. 4, 2005

Anyone like to commit 1028908? Patch was written by module author (me), including an important doc warning re (lack of) thread safety which I mistakenly thought had got into 2.4.0. John

1 0

[Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS, 1.1237, 1.1238
by Guido van Rossum Feb. 4, 2005

Feb. 4, 2005

[jhylton(a)users.sourceforge.net] > Log Message: > Add NEWS item about future parser bug. Give back the time machine! -- --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2