Mailman 3 October 2009 - Python-Dev

Can 3.1 still be built without complex?
by skip＠pobox.com 15 Oct '09

15 Oct '09

I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past? Skip

6 10

Python 2.6.4rc1
by Barry Warsaw 15 Oct '09

15 Oct '09

Hello everyone. The source tarballs and Windows installers for Python 2.6.4rc1 are now available: http://www.python.org/download/releases/2.6.4/ Please download them, install them, and try to use them with your projects and environments. Let us know if you encounter any problems with them. Hopefully we can avoid the situation with 2.6.3 having such critical bugs. 2.6.4 final is planned for 18-October. Cheers, -Barry

7 16

On track for Python 2.6.4 final this Sunday?
by Barry Warsaw 14 Oct '09

14 Oct '09

Are we on track to release 2.6.4 final this Sunday or do we need another rc? Yesterday, Tarek committed another setuptools related fix and said that he was going to run a bunch of build tests locally. Tarek, how did that go? Please note that issue 7064 is still open as a release blocker. Can we close that (again) now? http://bugs.python.org/issue7064 I am still being very conservative about what goes in 2.6.4. Only regressions introduced in 2.6.3 are being accepted. There's plenty of time after that for patches to go in for 2.6.5. -Barry

9 27

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?
by Anthony Baxter 13 Oct '09

13 Oct '09

I strongly urge another release candidate. But then, I am not doing the work, so take that advice for what it is... On Oct 14, 2009 10:18 AM, "Barry Warsaw" <barry(a)python.org> wrote: On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that the idea of a release ... No, but let's do one anyway! So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? -Barry _______________________________________________ python-committers mailing list python-committers(a)python.org http://mail.python.org/mailman/listinfo/python-committers

1 0

Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?
by P.J. Eby 13 Oct '09

13 Oct '09

At 05:16 PM 10/13/2009 +0200, Tarek Ziadé wrote: >Yes the doctest was pretty fuzzy about what is an extension name. It's >will be improved in 2.7. > >The current code is doing os.path.join()'s to join the Extension name >with the build path, >leading to the collateral damage you are mentioning. To fix the >problem, the API has to be as permissive >as it was before. > >I have already three or four tests to fix that problem in >test_build_ext. If you can take a look at them and >think of any other test that would be missing, that would be >appreciated. Another pair of eye is never enough. One identical to test_build_ext_path_with_os_sep, but that explicitly uses a '/' (rather than os.sep) will identify the problem I'm referring to, when run on Windows. It's common practice to use /-separated paths in setup scripts, regardless of platform. So, your current fix (converting os.sep to '.') will work on Linux, Mac, etc., but fail on Windows when run with the same setup.py, since os.sep is a backslash there. (Just as a side note, if when you split off issue 7115 you'd said what the new issue number was in 7064, or copied me to the nosy-list on the new issue, I'd have been able to review this change and comment on it yesterday instead of today, and I'd have done it in the bug tracker rather than via Python-Dev.)

2 1

PEP about sys.implementation and implementation specific user site directory
by Christian Heimes 13 Oct '09

13 Oct '09

Fellow Python developers! In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find some free time over the next weeks. Before I start with the PEP I like to reach consensus over the goal. Alternative implementations of our beloved programming languages are becoming more important every day. Although IronPython, Jython and PyPy are trying hard to get as compatible to CPython as possible there are numerous reasons for conditional code. General Python unit tests vs. CPython specific unit tests are one reasons, implementation specific module search paths are another. At the moment Python has no easy way to inspect the implementation besides some code in the platform module. I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix. sys.implementation ------------------ (Proposed by Nick, MAL and others.) sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness. id (required): lower case identifier, for example "cpython", "ironpython", "jython", "pypy" name (required): mixed case name of the implementation, for example "CPython", "IronPython", "Jython", "PyPy" platform (required): platform or language of the implementation, for example "C", ".NET", "Java" runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net" compiler (required): verbose name of the compiler, for example "GCC 4.3.3", "Java HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" ... sys.userdirsuffix ----------------- sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python. Examples: python2.6 (CPython, Unix) Python26 (CPython, Windows) ironpython2.6 (IronPython, Unix) IronPython26 (IronPython, Windows) ... Comments? Christian

14 32

PEP 370 and IronPython
by Christian Heimes 13 Oct '09

13 Oct '09

Dear Pythonistas! Michael Foord has written a blog posting [1] regarding IronPython, site packages and my PEP 370. I'm referring to the section that talks about an issue with PEP 370. --- If you install CPython 2.6 on Windows it creates a folder in the location: %APPDATA%\Python\Python26\site-packages. On my machine the full path is: C:\Users\michael\AppData\Roaming\Python\Python26\site-packages. This is put on the path by site.py when you run Python and as it is a user directory it doesn't require elevation to install there. You install into the user directory rather than the 'usual' location with: python setup.py --user install Herein lies another problem though. IronPython uses the standard Python site.py, meaning that currently it shares the user site-packages folder with CPython. This is not ideal as typically you will want separate libraries install for IronPython. When Jython ports to Python 2.6 it will have the same issue. --- I didn't think about IronPython during the design phase of the PEP. I didn't come into my mind that another implementation may require a different site packages directory. After spinning my head around the issue a simple solution came to me. The solution requires a new attribute in the sys module that contains the name of the implementation. As an alternative we could use the first field of sys.subversion but I prefer an explicit attribute. I'm proposing "sys.name" with a value of "CPython", "IronPython", "Jython" or "PyPy". The site module uses the information of the attribute to modify the path to the user site directory. The altered user site directories are: CPython: ~/.local/lib/python2.6/site-packages %APPDATA%/Python/Python26 IronPython: ~/.local/lib/ironpython2.6/site-packages %APPDATA%/Python/IronPython26 Jython: ~/.local/lib/jython2.6/site-packages %APPDATA%/Python/Jython26 Proposed patch: Index: Lib/site.py =================================================================== --- Lib/site.py (revision 75282) +++ Lib/site.py (working copy) @@ -74,7 +74,12 @@ USER_SITE = None USER_BASE = None +interpreter_name = getattr(sys, "name", "CPython") +if interpreter_name == "CPython": + # b/w compatible name + interpreter_name = "python" + def makepath(*paths): dir = os.path.abspath(os.path.join(*paths)) return dir, os.path.normcase(dir) @@ -253,10 +258,12 @@ return USER_SITE if os.name == "nt": - USER_SITE = os.path.join(user_base, "Python" + sys.version[0] + - sys.version[2], "site-packages") + USER_SITE = os.path.join(user_base, interpreter_name.capitalize() + + sys.version[0] + sys.version[2], + "site-packages") else: - USER_SITE = os.path.join(user_base, "lib", "python" + sys.version[:3], + USER_SITE = os.path.join(user_base, "lib", + interpreter_name.lower() + sys.version[:3], "site-packages") return USER_SITE The patch doesn't modify the search path for global directories. These can be changed by altering sys.prefix and sys.exec_prefix. Christian [1] http://ironpython-urls.blogspot.com/2009/10/distributing-ironpython-package…

23 40

Backport new float repr to Python 2.7?
by Mark Dickinson 12 Oct '09

12 Oct '09

In a recent #python-dev IRC conversation, it was suggested that we should consider backporting the new-style float repr from py3k to trunk. I'd like to get people's opinions on this idea. To recap quickly, the algorithm for computing the repr of floats changed between Python 2.x and Python 3.x (well, actually between 3.0 and 3.1, but 3.0 is dead): - in Python 2.x, repr(x) computes 17 significant decimal digits, and then strips trailing zeros. In other words, it's pretty much identical to doing '%.17g' % x. The computation is done using the platform's *printf functions. - in Python 3.x, repr(x) returns the shortest decimal string that's guaranteed to evaluate back to the float x under correct rounding. The computation is done using David Gay's dtoa.c code, adapted for inclusion in Python (in file Python/dtoa.c). There are (in my view) many benefits to the new approach. Among them: - fewer newbie complaints and questions (on c.l.p, IRC, Stack Overflow, etc.) about Python 'rounding incorrectly'. Whether this is a good thing or not is the matter of some debate (I'm tempted to borrow the time machine and simply say 'see the replies to this message'!) - string to float *and* float to string conversions are both guaranteed correctly rounded in 3.x: David Gay's code implements the conversion in both directions, and having correctly rounded string -> float conversions is essential to ensure that eval(repr(x)) recovers x exactly. - the repr of round(x, n) really does have at most n digits after the point, giving the semi-illusion that x really has been rounded exactly, and eliminating one of the most common user complaints about the round function. - round(x, n) agrees exactly with '{:.{}f}'.format(x, n) (this isn't true in Python 2.x, and the difference is a cause of bug reports) - side effects like finding that float(x) rounds correctly for Decimal instances x. - the output from the new rule is more consistent: the 'strip trailing zeros' part of the old rule has some strange consequences: e.g., in 2.x right now (on a typical machine): >>> 0.02 0.02 >>> 0.03 0.029999999999999999 even though neither 0.02 nor 0.03 can be exactly represented in binary. 3.x gives '0.02' and '0.03'. - repr(x) is consistent across platforms (or at least across platforms with IEEE 754 doubles; in practice this seems to account for virtually all platforms currently running Python). - the float <-> string conversions are under our control, so any bugs found can be fixed in the Python source. There's no shortage of conversion bugs in the wild, and certainly bugs have been observed in OS X, Linux and Windows. (The ones I found in OS X 10.5 have been fixed in OS X 10.6, though.) Possible problems: - breaking docstrings in third party code. Though Eric reminded me that when we implemented this for 3.1, there were essentially no standard library test breakages resulting from the changed repr format. - some might argue that the new repr (and round) just allows users to remain ignorant of floating-point difficulties for longer, and that this is a bad thing. I don't really buy either of these points. - someone has to put in the work. As mentioned below, I'm happy to do this (and Eric's offered to help, without which this probably wouldn't be feasible at all), but it'll use cycles that I could also usefully be spending elsewhere. I'm mostly neutral on the backport idea: I'm very happy that this is in 3.x, but don't see any great need to backport it. But if there's majority (+BDFL) support, I'm willing to put the work in to do the backport. Masochists who are still reading by this point and who want more information about the new repr implementation can see the issue discussion: http://bugs.python.org/issue1580 Thoughts? Mark

11 19

Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Simon Cross 12 Oct '09

12 Oct '09

On Thu, Oct 8, 2009 at 10:31 AM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > = Virtualenv and the multiple version support in Distribute = ... > My opinion is that this tool exists only because Python doesn't > support the installation of multiple versions for the same > distributions. This is not at all how I use virtualenv. For me virtualenv is a sandbox so that I don't have to become root whenever I need to install a Python package for testing purposes and to allow me to hop between sets of installed Python packages while developing on multiple Python projects. I also use it as a sandbox for build bots so that multiple bots on the same machine can each build their own projects with just the known dependencies installed. Schiavo Simon

9 13

Weak dict iterators are fragile
by Antoine Pitrou 11 Oct '09

11 Oct '09

Hello, In py3k, the weak dict methods keys(), values() and items() have been changed to return iterators (they returned lists in 2.x). However, it turns out that it makes these methods quite fragile, because a GC collection can occur whenever during iterating, destroy one of the weakref'ed objects, and trigger a resizing of the underlying dict, which in turn raises an exception ("RuntimeError: dictionary changed size during iteration"). This has just triggered (assuming the diagnosis is correct) a hang in test_multiprocessing: http://bugs.python.org/issue7060 I would like to propose some possible solutions against this: 1. Add the safe methods listkeys(), listitems(), listvalues() which would behave as the keys(), etc. methods from 2.x 2. Make it so that keys(), items(), values() atomically build a list of items internally, which makes them more costly for large weak dicts, but robust. What do you think? Regards Antoine.

2 4

Initialization of __builtins__
by Vinay Sajip 10 Oct '09

10 Oct '09

>I'm not top-posting, but gmane is giving me a hard time :-( In the py3k branch, logging has the line _unicode = 'unicode' in dir(__builtins__) to determine the existence of Unicode support. The code in trunk, being 1.5.2 compatible, used hasattr(types, 'UnicodeType') I wanted to eliminate the types import and modernise the trunk code a bit, so I copied the py3k line to the trunk version of logging. It didn't work as expected! So I added the line print dir(__builtins__) in logging fairly early on (though not the very first line - just after the __date__ = ... line. Here's what I got with 2.7a0 and 2.6.1: Python 2.7a0 (trunk:75292M, Oct 9 2009, 09:21:05) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging ['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values'] >>> ActivePython 2.6.1.1 (ActiveState Software Inc.) based on Python 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging ['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values'] >>> However, if I just do dir(__builtins__) in the interactive prompt, I get the whole shebang. Excuse my ignorance, but how come? Regards, Vinay Sajip

4 4

transitioning from % to {} formatting
by Steven Bethard 10 Oct '09

10 Oct '09

There's a lot of code already out there (in the standard library and other places) that uses %-style formatting, when in Python 3.0 we should be encouraging {}-style formatting. We should really provide some sort of transition plan. Consider an example from the logging docs: logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s") We'd like to support both this style as well as the following style: logging.Formatter("{asctime} - {name} - {levelname} - {message}") Perhaps we'd eventually deprecate the %-style formatting, but at least in the intervening time, we'd have to support both. I see a few possibilities: * Add a new class, NewFormatter, which uses the {}-style formatting. This is ugly because it makes the formatting we're trying to encourage look like the alternative implementation instead of the standard one. It also means we have to come up with new names for every API that uses format strings. * Have Formatter try to guess whether it got %-style formatting or {}-style formatting, and then delegate to the appropriate one. I don't know how accurately we can guess. We also end up still relying on both formatting styles under the hood. * Have Formatter convert all %-style formatting strings to {}-style formatting strings (automatically). This still involves some guessing, and involves some serious hacking to translate from one to the other (maybe it wouldn't even always be possible?). But at least we'd only be using {}-style formatting under the hood. Thoughts? Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

26 131

Re: [Python-Dev] eggs now mandatory for pypi?
by Senthil Kumaran 10 Oct '09

10 Oct '09

On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote: > it's revews like this that makes me wonder if releasing open source is > a good idea: > no egg - worst seen ever, remove it from pypi or provide an egg > (jensens, 2009-10-05, 0 points) > Greetings effbot. :) As you might already know, "eggs" are not mandatory for pypi. No where in the documentation it mentions so. Also many good packages in pypi are not eggs (MaL's egenix packages for e.g) and we have known his dislike for that particular format too. But still, sometimes people have found eggs to be convenient. That was a particularly harsh comment from jensens, should be ignored or he should be corrected that eggs are not mandatory. But, i have a feeling that this is going to open up the well known, can-of-worms on what is the best distribution format for python packages debate. -- Senthil No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, "Spock's Brain", stardate 5431.6

9 29

Re: [Python-Dev] a new setuptools release?
by P.J. Eby 09 Oct '09

09 Oct '09

At 12:16 PM 10/6/2009 -0700, Guido van Rossum wrote: >I think at this point the community should not be forced wait for you >to get a new supply of round tuits. The wait has been too long >already. You can stay on in an advisory role, but I don't think it's >reasonable to block development or decisions until you have time. Tarek didn't think so either, which is why he created a fork, called Distribute. So I'm not really clear on what you're trying to say here (or in the rest of the email, for that matter).

9 11

Howto handle multilib conflict?
by Neal Becker 09 Oct '09

09 Oct '09

Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237 yum install libotf-devel.i586 libotf-devel.x86_64 yields: Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 What is the recommended way to resolve this?

1 1

Summary of Python tracker Issues
by Python tracker 09 Oct '09

09 Oct '09

ACTIVITY SUMMARY (10/02/09 - 10/09/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2444 open (+44) / 16471 closed (+14) / 18915 total (+58) Open issues with patches: 976 Average duration of open issues: 670 days. Median duration of open issues: 420 days. Open Issues Breakdown open 2410 (+44) pending 33 ( +0) Issues Created Or Reopened (59) _______________________________ traceback.format_exception_only does not return SyntaxError caro 10/07/09 http://bugs.python.org/issue6962 reopened thewtex patch Doc/reference/datamodel: Slots description needs update 10/02/09 http://bugs.python.org/issue7036 created Byron patch test_asynchat fails on os x 10.6 10/02/09 http://bugs.python.org/issue7037 created chuck test_curses fails on os x 10.6 10/02/09 http://bugs.python.org/issue7038 created chuck test_distutils fails on os x 10.6 10/02/09 CLOSED http://bugs.python.org/issue7039 created chuck test_smtplib fails on os x 10.6 10/02/09 http://bugs.python.org/issue7040 created chuck test_macostools fails on os x 10.6 10/02/09 http://bugs.python.org/issue7041 created chuck test_signal fails on os x 10.6 10/02/09 http://bugs.python.org/issue7042 created chuck patch test_urllib: constructLocalFileUrl returns invalid URLs on Windo 10/03/09 http://bugs.python.org/issue7043 created srid urllib.urlopen crashes when used on Mac OS 10.6.1 through a prox 10/03/09 http://bugs.python.org/issue7044 created jweber utf-8 encoding error 10/03/09 http://bugs.python.org/issue7045 created ArcRiley decimal.py: use DivisionImpossible and DivisionUndefined 10/03/09 http://bugs.python.org/issue7046 created skrah decimal.py: NaN payload conversion 10/03/09 CLOSED http://bugs.python.org/issue7047 created skrah decimal.py: logb: round the result if it is greater than prec 10/03/09 http://bugs.python.org/issue7048 created skrah patch decimal.py: NaN result in pow(x, y, z) with prec 1 10/03/09 http://bugs.python.org/issue7049 created skrah patch Augmented assignment of tuple crashes IDLE 10/03/09 CLOSED http://bugs.python.org/issue7050 created mfitz 'g'/'G' format docs need a little more explanation 10/03/09 http://bugs.python.org/issue7051 created benjamin.peterson "from logging import *" causes an error under Ubuntu Karmic 10/04/09 CLOSED http://bugs.python.org/issue7052 created vak wrong overload of slot wrapper 10/04/09 CLOSED http://bugs.python.org/issue7053 created omatt Python25.chm seems to be broken 10/04/09 CLOSED http://bugs.python.org/issue7054 created Mark77 Automatic test___all__ 10/04/09 http://bugs.python.org/issue7055 created pitrou patch regrtest runtest_inner calls findtestdir unnecessarily 10/04/09 http://bugs.python.org/issue7056 created r.david.murray patch tkinter doc: more 3.x updates 10/04/09 http://bugs.python.org/issue7057 created tjreedy Add some test execution environment protection to regrtest 10/04/09 http://bugs.python.org/issue7058 created r.david.murray patch 'checking getaddrinfo bug' doesn't output the result during ./co 10/05/09 http://bugs.python.org/issue7059 created ezio.melotti test_multiprocessing dictionary changed size errors and hang 10/05/09 http://bugs.python.org/issue7060 created r.david.murray Improve 24.5. turtle doc 10/05/09 http://bugs.python.org/issue7061 created tjreedy No docs for module 'IN' 10/05/09 http://bugs.python.org/issue7062 created RSokolov Memory errors in array.array 10/05/09 http://bugs.python.org/issue7063 created chuck Python 2.6.3 / setuptools 0.6c9: extension module builds fail wi 10/05/09 CLOSED http://bugs.python.org/issue7064 reopened tarek bytes.maketrans segfaults 10/05/09 http://bugs.python.org/issue7065 created egreen patch archive_util.make_archive doesn't restore the cwd if an error is 10/05/09 http://bugs.python.org/issue7066 created ezio.melotti Suggest better documentation of 2 versus 3 on 3.1.1 site. 10/05/09 http://bugs.python.org/issue7067 created srl 2.6.3 does not use specified compiler 10/06/09 CLOSED http://bugs.python.org/issue7068 created gotoh inspect.isabstract to return boolean values only 10/06/09 http://bugs.python.org/issue7069 created gagenellina patch round(x) gives wrong result for large odd integers 10/06/09 http://bugs.python.org/issue7070 created mark.dickinson easy distutils and IronPython compatibility 10/06/09 http://bugs.python.org/issue7071 created michael.foord 26backport isspace(0xa0) is true on Mac OS X 10/06/09 http://bugs.python.org/issue7072 created naoki Python 2.6.3 final windows installer installs a release candida 10/06/09 CLOSED http://bugs.python.org/issue7073 created jamartinh Turtle module crashes python 10/06/09 http://bugs.python.org/issue7074 created tjreedy Bug while put a set on a dict 10/07/09 CLOSED http://bugs.python.org/issue7075 created chucheng Documentation add note about SystemRandom 10/07/09 http://bugs.python.org/issue7076 created sligocki patch SysLogHandler can't handle Unicode 10/07/09 http://bugs.python.org/issue7077 created rszefler struct help in the interpreter does not explain about the fmt op 10/07/09 http://bugs.python.org/issue7078 created orsenthil patch, easy file_close() ignores return value of close_the_file 10/07/09 http://bugs.python.org/issue7079 created stutzbach patch locale.strxfrm raises MemoryError 10/07/09 http://bugs.python.org/issue7080 created egreen patch ">" formatting behaving like "=" formatting 10/08/09 CLOSED http://bugs.python.org/issue7081 created ncoghlan Patch for get_filename in email.message when content-disposition 10/08/09 http://bugs.python.org/issue7082 created DazWorrall patch locals() behaviour differs when tracing is in effect 10/08/09 CLOSED http://bugs.python.org/issue7083 created andbj printing a list releases the GIL carelessly 10/08/09 http://bugs.python.org/issue7084 created pitrou strptime problem 10/08/09 http://bugs.python.org/issue7085 created kakacek logging.handlers.SysLogHandler with TCP support 10/08/09 http://bugs.python.org/issue7086 created enigma patch use keyword 'as' in _xmlplus 10/09/09 CLOSED http://bugs.python.org/issue7087 created s7v7nislands New (in 2.6) functions in signal module are not documented as un 10/09/09 http://bugs.python.org/issue7088 created stutzbach shlex behaves unexpected if newlines are not whitespace 10/09/09 http://bugs.python.org/issue7089 created jjdmol2 patch encoding uncode objects greater than FFFF 10/09/09 CLOSED http://bugs.python.org/issue7090 created msaghaei Distutils build ignores the --compiler command line option 10/09/09 http://bugs.python.org/issue7091 created jmb Test suite emits many DeprecationWarnings when -3 is enabled 10/09/09 http://bugs.python.org/issue7092 created exarkun xmlrpclib.ServerProxy() doesn't support unicode uri 10/09/09 http://bugs.python.org/issue7093 created haypo patch Issues Now Closed (30) ______________________ fromfd() and dup() for _socket on WIndows 701 days http://bugs.python.org/issue1378 planders patch unittest.py sys.exit error 510 days http://bugs.python.org/issue2821 mfitz fix_idioms.py generates bad code 418 days http://bugs.python.org/issue3563 benjamin.peterson patch distutils.util.get_platform() is wrong for universal builds on m 366 days http://bugs.python.org/issue4064 ronaldoussoren patch, needs review make io.BufferedWriter observe max_buffer_size limits 318 days http://bugs.python.org/issue4428 pitrou patch, needs review PEP 383 implementation 157 days http://bugs.python.org/issue5915 exarkun patch reset owner/group to root for distutils tarballs 80 days http://bugs.python.org/issue6516 bheemesh subprocess issue on Win 7 x64 44 days http://bugs.python.org/issue6773 tesla unmarshaling of artificial strings can produce funny longs. 4 days http://bugs.python.org/issue7019 mark.dickinson patch Doc update for io module 5 days http://bugs.python.org/issue7022 pakal webbrowser : Could not open ftp server using webbrowser.open() 5 days http://bugs.python.org/issue7024 orsenthil test_urllib: unsetting missing 'env' variable 4 days http://bugs.python.org/issue7026 orsenthil Add int.hex for symmetry with float.hex 1 days http://bugs.python.org/issue7028 mark.dickinson Improve pybench 8 days http://bugs.python.org/issue7029 krisvale patch test_distutils fails on os x 10.6 0 days http://bugs.python.org/issue7039 ned.deily decimal.py: NaN payload conversion 0 days http://bugs.python.org/issue7047 mark.dickinson Augmented assignment of tuple crashes IDLE 0 days http://bugs.python.org/issue7050 benjamin.peterson "from logging import *" causes an error under Ubuntu Karmic 1 days http://bugs.python.org/issue7052 srid wrong overload of slot wrapper 0 days http://bugs.python.org/issue7053 georg.brandl Python25.chm seems to be broken 0 days http://bugs.python.org/issue7054 Mark77 Python 2.6.3 / setuptools 0.6c9: extension module builds fail wi 1 days http://bugs.python.org/issue7064 schmir 2.6.3 does not use specified compiler 0 days http://bugs.python.org/issue7068 tarek Python 2.6.3 final windows installer installs a release candida 0 days http://bugs.python.org/issue7073 ezio.melotti Bug while put a set on a dict 0 days http://bugs.python.org/issue7075 benjamin.peterson ">" formatting behaving like "=" formatting 0 days http://bugs.python.org/issue7081 ncoghlan locals() behaviour differs when tracing is in effect 0 days http://bugs.python.org/issue7083 andbj use keyword 'as' in _xmlplus 0 days http://bugs.python.org/issue7087 benjamin.peterson encoding uncode objects greater than FFFF 0 days http://bugs.python.org/issue7090 ezio.melotti urllib doesn't correct server returned urls 2030 days http://bugs.python.org/issue918368 AdamN patch Generate numeric/space/linebreak from Unicode database. 1098 days http://bugs.python.org/issue1571184 amaury.forgeotdarc patch Top Issues Most Discussed (10) ______________________________ 16 UnicodeEncodeError - I can't even see license 250 days open http://bugs.python.org/issue5127 13 'g'/'G' format docs need a little more explanation 6 days open http://bugs.python.org/issue7051 13 test_signal fails on os x 10.6 7 days open http://bugs.python.org/issue7042 11 "from logging import *" causes an error under Ubuntu Karmic 1 days closed http://bugs.python.org/issue7052 11 decimal.py: NaN result in pow(x, y, z) with prec 1 6 days open http://bugs.python.org/issue7049 11 decimal.py: logb: round the result if it is greater than prec 6 days open http://bugs.python.org/issue7048 9 Python 2.6.3 / setuptools 0.6c9: extension module builds fail w 1 days closed http://bugs.python.org/issue7064 9 expat parser throws Memory Error when parsing multiple files 60 days open http://bugs.python.org/issue6676 9 array.fromfile not checking I/O errors 223 days open http://bugs.python.org/issue5395 8 utf-8 encoding error 7 days open http://bugs.python.org/issue7045

1 0

Re: [Python-Dev] [New-bugs-announce] [issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
by skip＠pobox.com 09 Oct '09

09 Oct '09

Ned> Due to a change in distutils released with Python 2.6.3, packages Ned> that use setuptools (version 0.6c9, as of this writing), or the Ned> easy_install command, to build C extension modules fail ... ... Ned> Among the packages known to be affected include lxml, Ned> zope-interface, jinja2, and, hence, packages dependent on these Ned> packages (e.g. sphinx, twisted, etc.). Maybe the Python test suite should include tests with a small number of widely used non-core packages like setuptools. I realize the pybots project exists to tackle this sort of stuff in greater detail. I'm thinking more of a smoke test than a comprehensive test suite covering all external packages. Setuptools is particularly important because so many extension authors use it. If it breaks it implicitly breaks a lot of PyPI packages. Skip

4 3

Logging, Unicode and sockets
by Vinay Sajip 08 Oct '09

08 Oct '09

> Thanks to http://bugs.python.org/issue7077 I've noticed that the socket-based logging handlers - SocketHandler, DatagramHandler and SysLogHandler - aren't Unicode-aware and can break in the presence of Unicode messages. I'd like to fix this by giving these handlers an optional (encoding=None) parameter in their __init__, and then using this to encode on output. If no encoding is specified, is it best to use locale.getpreferredencoding(), sys.getdefaultencoding(), sys.getfilesystemencoding(), 'utf-8' or something else? On my system: >>> sys.getdefaultencoding() 'ascii' >>> sys.getfilesystemencoding() 'mbcs' >>> locale.getpreferredencoding() 'cp1252' which suggests to me that the locale.getpreferredencoding() should be the default. However, as I'm not a Unicode maven, any suggestions would be welcome. Regards, Vinay Sajip

3 3

PEP 389: argparse - new command line parsing module
by Steven Bethard 08 Oct '09

08 Oct '09

On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson <benjamin(a)python.org> wrote: > 2009/9/27 Steven Bethard <steven.bethard(a)gmail.com>: >> The first release where any real deprecation message would show up is >> Python 3.4, more than 3 years away. If you think 3 years isn't long >> enough for people to be over the Python 3 transition, let's stick in >> another version in there and make it 4.5 years. > > So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

27 72

locals() different behaviour when tracing?
by Anders Waldenborg 08 Oct '09

08 Oct '09

Is it intentional that locals() returns a copy/snapshot of the local variables sometimes, and sometimes a reference? Like when enabling tracing, such as in the code pasted below. The documentation ("Update and return a dictionary containing the current scope's local variables.") is pretty unclear. import sys def X(): l = locals() i = "foo" print "Is 'i' in stored locals()? ", ('i' in l) print "Running normally" X() print "Enabling tracing" def t(*a): return t sys.settrace(t) X()

3 2

please consider changing --enable-unicode default to ucs4
by Zooko O'Whielacronx 08 Oct '09

08 Oct '09

Dear Pythonistas: This issue causes serious problems. Users occasionally get binaries built for a compatible Linux and Python version but with a different UCS2-vs-UCS4 setting, and those users get mysterious memory corruption errors which are hard to diagnose. It is possible that these situations also open up security vulnerabilities. A couple such instances are documented on http://bugs.python.org/setuptools/issue78, but you can find more by googling. I would like to get this problem fixed! In order to help address this issue I sampled what UCS size is used by python executables in the wild. I instrumented a few buildslaves that are contributed by various people to the Tahoe-LAFS project to print out their platform, python version, and sys.maxunicode. The full results are appended below. maxunicode: 1114111 means that python executable was configured with --enable-unicode=ucs4, and maxunicode: 65535 means that python executable was configured with --enable-unicode=ucs2 or just with --enable-unicode . The only incompatibilities that I found are because some packagers have deliberately set UCS4 configuration and other packagers have left the default setting. In the three cases where someone configured python with UCS2, one of the three is certainly an accident (a custom-built python executable on an Ubuntu server) and the other two just use the default instead of specifically configuring ucs2 in their configurations of Python and I suspect that they don't know the difference and that it was an accident that they built a Python incompatible with other distributions of their operating system. In sum, while it would be good to add the unicode setting to the platform's ABI (as discussed in setuptools ticket #78), it would also be good to make the default value be UCS4 instead of UCS2. This would fix all three of the potential incompatibilities that I found (listed below), and once we have proper inclusion of the unicode setting in the ABI in order to prevent the memory corruption, defaulting to UCS4 would increase the likelihood that a binary built on one distribution would be usable on another. I'm sure that someone can come up with a reason why UCS2 is better than UCS4, but I'm also sure that the benefits of compatibility outweigh any benefits of UCS2 encoding, and that the widespread use of UCS4 demonstrates that there is nothing fatally wrong with it, and that people who really value UCS2 encoding more than compatibility can choose that for themselves by explicitly setting UCS2. Let me restate that I am not suggesting taking away anyone's options, only making the setting for people who don't specify default to the compatible option. Hm, I guess that means that it should default to UCS2 on Windows and Mac and to UCS4 on Linux and Solaris. Regards, Zooko Ubuntu 6.10 "edgy" i386: python: 2.4.4c1 (#2, Mar 7 2008, 03:03:38) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)], maxunicode: 1114111 Ubuntu 7.04 "feisty": python: 2.5.1 (r251:54863, Jul 31 2008, 22:53:39) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)], maxunicode: 1114111 Ubuntu 7.10 "gutsy" i386: python: 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)], maxunicode: 1114111 Ubuntu 8.04 "hardy" amd64: python: 2.5.2 (r252:60911, Jul 22 2009, 15:33:10) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)], maxunicode: 1114111 Ubuntu 8.04 "hardy" i386: *custom* python: 2.6 (r26:66714, Oct 2 2008, 13:40:28) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)], maxunicode: 65535 Ubuntu 8.04 "hardy" i386: python: 2.5.2 (r252:60911, Jul 22 2009, 15:35:03) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)], maxunicode: 1114111 Ubuntu 9.04 "jaunty" amd64: *custom* python: 2.6.2 (release26-maint, Apr 19 2009, 01:58:18) [GCC 4.3.3], maxunicode: 1114111 Debian 4.0 "etch" i386: python: 2.4.4 (#2, Oct 22 2008, 19:52:44) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)], maxunicode: 1114111 Debian 5.0 "lenny" i386: python: 2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC 4.3.2], maxunicode: 1114111 Debian 5.0 "lenny" amd64: python: 2.5.2 (r252:60911, Jan 4 2009, 21:59:32) [GCC 4.3.2], maxunicode: 1114111 Debian 5.0 "lenny" armv5tel: python: 2.5.2 (r252:60911, Jan 5 2009, 02:00:00) [GCC 4.3.2], maxunicode: 1114111 Debian unstable "squeeze/sid" i386: python: 2.5.4 (r254:67916, Feb 17 2009, 20:16:45) [GCC 4.3.3], maxunicode: 1114111 Fedora 11 "leonidas" amd64: python: 2.6 (r26:66714, Jul 4 2009, 17:37:13) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)], maxunicode: 1114111 ArchLinux: python: 2.6.2 (r262:71600, Jul 20 2009, 02:23:30) [GCC 4.4.0 20090630 (prerelease)], maxunicode: 65535 NetBSD 4: python: 2.5.2 (r252:60911, Mar 20 2009, 14:00:07) [GCC 4.1.2 20060628 prerelease (NetBSD nb2 20060711)], maxunicode: 65535 OpenSolaris SunOS-5.11-i86pc-i386-32bit: python: 2.4.4 (#1, Mar 10 2009, 09:35:36) [C], maxunicode: 65535 Nexenta NCP1 SunOS-5.11-i86pc-i386-32bit: python: 2.4.3 (#2, May 3 2006, 19:12:42) [GCC 4.0.3 (GNU_OpenSolaris 4.0.3-1nexenta4)], maxunicode: 1114111 Mac OS 10.6 "snow leopard" i386: python: 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)], maxunicode: 65535 Mac OS 10.5 "leopard" i386: python: 2.5.1 (r251:54863, Feb 6 2009, 19:02:12) [GCC 4.0.1 (Apple Inc. build 5465)], maxunicode: 65535 Mac OS 10.4 "tiger" *custom* python: 2.5.4 (release25-maint:72153M, Apr 30 2009, 12:28:20) [GCC 4.0.1 (Apple Computer, Inc. build 5367)], maxunicode: 65535 Cygwin CYGWIN_NT-5.1-1.5.25-0.156-4-2-i686-32bit-WindowsPE: python: 2.5.2 (r252:60911, Dec 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)], maxunicode: 65535 Windows: python: 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)], maxunicode: 65535 Windows: python: 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)], maxunicode: 65535

7 13

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4
by M.-A. Lemburg 07 Oct '09

07 Oct '09

Zooko O'Whielacronx wrote: > Folks: > > I'm sorry, I think I didn't make my concern clear. My users, and lots > of other users, are having a problem with incompatibility between > Python binary extension modules. One way to improve the situation > would be if the Python devs would use their "bully pulpit" -- their > unique position as a source respected by all Linux distributions -- > and say "We recommend that Linux distributions use UCS4 for > compatibility with one another". This would not abrogate anyone's > ability to choose their preferred setting nor, as far as I can tell, > would it interfere with the ongoing development of Python. -1 Please note that we did not choose to ship Python as UCS4 binary on Linux - the Linux distributions did. The Python default is UCS2 for a good reason: it's a good trade-off between memory consumption, functionality and performance. As already mentioned, I also don't understand how the changing the Python default on Linux would help your users in any way - if you let distutils compile your extensions, it's automatically going to use the right Unicode setting for you (as well as your users). Unfortunately, this automatic support doesn't help you when shipping e.g. setuptools eggs, but this is a tool problem, not one of Python: setuptools completely ignores the fact that there are two ways to build Python. I'd suggest you ask the tool maintainers to adjust their tools to support the Python Unicode option. > Here are the details: > > I'm the maintainer of several Python packages. I work hard to make it > easy for users, even users who don't know anything about Python, to > use my software. There have been many pain points in this process and > I've spent a lot of time on it for about three years now working on > packaging, including the tools such as setuptools and distutils and > the new "distribute" tool. Python packaging has been improving during > these years -- things are looking up. > > One of the remaining pain points is that I can distribute binaries of > my Python extension modules for Windows or Mac, but if I distribute a > binary Python extension module on Linux, then if the user has a > different UCS2/UCS4 setting then they won't be able to use the > extension module. The current de facto standard for Linux is UCS4 -- > it is used by Debian, Ubuntu, Fedora, RHEL, OpenSuSE, etc. etc.. The > vast majority of Linux users in practice have UCS4, and most binary > Python modules are compiled for UCS4. > > That means that a few folks will get left out. Those folks, from my > experience, are people who built their python executable themselves > without specifying an override for the default, and the smaller Linux > distributions who insist on doing whatever upstream Python devs > recommend instead of doing whatever the other Linux distros are doing. > One of the data points that I reported was a Python interpreter that > was built locally on an Ubuntu server. Since the person building it > didn't know to override the default setting of --enable-unicode, he > ended up with a Python interpreter built for UCS2, even though all the > Python extension modules shipped by Ubuntu were built with UCS4. People building their own Python version will usually also build their own extensions, so I don't really believe that the above scenario is very common. Also note that Python will complain loudly when you try to load a UCS2 extension in a UCS4 build and vice-versa. We've made sure that any extension using the Python Unicode C API has to be built for the same UCS version of Python. This is done by using different names for the C APIs at the C level. > These are not isolated incidents. The following google searches > suggest that a number of people spend time trying to figure out why > Python extension modules fail on their linux systems: > > http://www.google.com/search?q=PyUnicodeUCS4_FromUnicode+undefined+symbol > http://www.google.com/search?q=+PyUnicodeUCS2_FromUnicode+undefined+symbol > http://www.google.com/search?q=_PyUnicodeUCS2_AsDefaultEncodedString+undefi… Perhaps we should add a FAQ entry for these linker errors (which are caused by the mentioned C API changes to prevent mixing UCS version) ?! Here's a quick way to determine you Python Unicode build type: python -c "import sys;print((sys.maxunicode<66000)and'UCS2'or'UCS4')" Perhaps we should include this info as well as an 32/64-bit indicator and the processor type in the Python startup line: # python Python 2.6 (r26:66714, Feb 3 2009, 20:49:49, UCS4, 64-bit, x86_64) [GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2 Type "help", "copyright", "credits" or "license" for more information. This would help users find the right binaries to install as extension. > Another data point is the Mandriva Linux distribution. It is probably > much smaller than Debian, Ubuntu, or RedHat, but it is still one of > the major, well-known distributions. I requested of the Python > maintainer for Mandriva, Michael Scherer, that they switch from UCS2 > to UCS4 in order to reduce compatibility problems like these. His > answer as I understood it was that it is best to follow the > recommendations of the upstream Python devs by using the default > setting instead of choosing a setting for himself. Which is IMHO what all Linux distributions should have done. Distributions should really not be put in charge of upstream coding design decisions. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 28 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

8 14

Re: [Python-Dev] a new setuptools release?
by P.J. Eby 07 Oct '09

07 Oct '09

At 01:14 PM 10/6/2009 -0700, Guido van Rossum wrote: >suggest nobody hold their breath waiting for setuptools 0.7. I've never suggested or implied otherwise. But, if you like Distribute so much, why not just add it directly to the stdlib? ;-) AFAIK, the only reason they've had multiple releases of it is to address the issues with its hijacking of setuptools; in a stdlib version all that stuff could be dropped. Otherwise, it'd already be "mature". There are many wins to be had from such a move, not the least of which is that it allows something to go into the stdlib that isn't (branding-wise) associated with me or setuptools, and lets it become owned/supported by an even wider community. Less political bickering, and the some of the technical results I hoped for all along are achieved. Yay, open source.

10 17

please consider changing --enable-unicode default to ucs4
by Zooko O'Whielacronx 07 Oct '09

07 Oct '09

Folks: I accidentally sent this letter just to MAL when I intended it to python-dev. Please read it, as it explains why the issue I'm raising is not just the "we should switch to ucs4 because it is better" issue that was previously settled by GvR. This is a current, practical problem that is preventing people from distributing and using Python packages with binary extension modules on Linux. Regards, Zooko ---------- Forwarded message ---------- From: Zooko O'Whielacronx <zookog(a)gmail.com> Date: Sun, Sep 27, 2009 at 11:43 AM Subject: Re: [Python-Dev] please consider changing --enable-unicode default to ucs4 To: "M.-A. Lemburg" <mal(a)egenix.com> Folks: I'm sorry, I think I didn't make my concern clear. My users, and lots of other users, are having a problem with incompatibility between Python binary extension modules. One way to improve the situation would be if the Python devs would use their "bully pulpit" -- their unique position as a source respected by all Linux distributions -- and say "We recommend that Linux distributions use UCS4 for compatibility with one another". This would not abrogate anyone's ability to choose their preferred setting nor, as far as I can tell, would it interfere with the ongoing development of Python. Here are the details: I'm the maintainer of several Python packages. I work hard to make it easy for users, even users who don't know anything about Python, to use my software. There have been many pain points in this process and I've spent a lot of time on it for about three years now working on packaging, including the tools such as setuptools and distutils and the new "distribute" tool. Python packaging has been improving during these years -- things are looking up. One of the remaining pain points is that I can distribute binaries of my Python extension modules for Windows or Mac, but if I distribute a binary Python extension module on Linux, then if the user has a different UCS2/UCS4 setting then they won't be able to use the extension module. The current de facto standard for Linux is UCS4 -- it is used by Debian, Ubuntu, Fedora, RHEL, OpenSuSE, etc. etc.. The vast majority of Linux users in practice have UCS4, and most binary Python modules are compiled for UCS4. That means that a few folks will get left out. Those folks, from my experience, are people who built their python executable themselves without specifying an override for the default, and the smaller Linux distributions who insist on doing whatever upstream Python devs recommend instead of doing whatever the other Linux distros are doing. One of the data points that I reported was a Python interpreter that was built locally on an Ubuntu server. Since the person building it didn't know to override the default setting of --enable-unicode, he ended up with a Python interpreter built for UCS2, even though all the Python extension modules shipped by Ubuntu were built with UCS4. These are not isolated incidents. The following google searches suggest that a number of people spend time trying to figure out why Python extension modules fail on their linux systems: http://www.google.com/search?q=PyUnicodeUCS4_FromUnicode+undefined+symbol http://www.google.com/search?q=+PyUnicodeUCS2_FromUnicode+undefined+symbol http://www.google.com/search?q=_PyUnicodeUCS2_AsDefaultEncodedString+undefi… Another data point is the Mandriva Linux distribution. It is probably much smaller than Debian, Ubuntu, or RedHat, but it is still one of the major, well-known distributions. I requested of the Python maintainer for Mandriva, Michael Scherer, that they switch from UCS2 to UCS4 in order to reduce compatibility problems like these. His answer as I understood it was that it is best to follow the recommendations of the upstream Python devs by using the default setting instead of choosing a setting for himself. (Now we could implement a protocol which would show whether a given Python package was compiled for UCS2 or UCS4. That would be good. Hopefully it would make incompatibility more explicit and understandable to users. Here is a ticket for that -- which project I am contributing to: http://bugs.python.org/setuptools/issue78 . However, even if we implement that feature in the distribute tool (the successor to setuptools), users who build their own python or who use a Linux distribution that follows upstream configuration defaults will still be unable to use most Python packages with compiled extension modules.) In a message on this thread, MvL wrote: > "For that reason I think it's also better that the configure script > continues to default to UTF-16 -- this will give the UTF-16 support > code the necessary exercise." > > This is effectively a BDFL pronouncement. Nothing has changed the > validity of the premise of the statement, so the conclusion remains > valid, as well. My understand of the earlier thread was that someone suggested that UCS4 would be technically better and GvR decided that there were technical reasons to continue actively maintaining the UCS2 code. This thread is different: I'm saying that users are suffering packaging problems and asking for help with that. The way that python-dev can help is to make it so that people who choose "Whatever the upstream devs prefer" (--enable-unicde) on Linux get the de facto standard setting. In the earlier thread, GvR wrote: "I think we should continue to leave this up to the distribution. AFAIK many Linux distros already use UCS4 for everything anyway.". But at least some distributions are asking the upstream Python devs to choose for them, by leaving the setting at the default. Hm, pondering GvR's words: "I think we should continue to leave this up to the distribution", I have a new proposal: make it so that *on Linux only* "--enable-unicode" errors out with an error message saying "please choose either --enable-unicode=ucs2 or --enable-unicode=ucs4. ucs4 is the most widely used setting on Linux. See http://python.org/wiki/UCS2_vs_UCS4 for details.". This would force those Linux distributions who are *not* currently deciding to decide. Thank you for your attention. Regards, Zooko

2 1

Package install failures in 2.6.3
by Ned Deily 07 Oct '09

07 Oct '09

There has been some discussion on the distutils-sig list over the past few days about a change to distutils released with 2.6.3 which inadvertently causes a number (all?) packages with C extensions that use setuptools/easy_install to fail during builds/installs with a rather cryptic error message. A number of popular packages are affected directly or indirectly through dependencies. The problem is summarized in the issue tracker here; http://bugs.python.org/issue7064 which includes links to the distutils list archive and the setuptools and Distribute project bug trackers. Assuming that distutils is not changed in a forthcoming 2.6.4, users and, possibly package maintainers, will need to take some action: either migrate from setuptools to Distribute (an easy migration), or wait for a fix to setuptools or the package or to the distribution (if there is one). I'm not proposing to debate the merits of all of the options here. However, if a 2.6.4 release is to be pushed out quickly for other reasons, a one-time window of opportunity would be available and it would be prudent to at least consider the possibility of a distutils fix. In any case, it seems like there should be some effort to make package maintainers aware of the problem so they can take whatever steps necessary to update their packages or help files or web sites etc. -- Ned Deily, nad(a)acm.org

16 32

Python byte-compiled and optimized code
by Swapnil Talekar 07 Oct '09

07 Oct '09

I am working on deploying Python on VxWorks platform as a part of project for my company. Accordingly, I would like to know couple of things from python's core-developers. Although I think I already know the answers for most of the questions, we need a confirmation from the community 1) Is the byte-compiled .pyc file and optimized .pyo file platform-independent?(including python versions 3.x) *If yes, is it guaranteed to stay that way in future?* 2) If the the generation of .pyc file fails (say, due to write protected area), does that stop the script execution? 3) Is it possible to redirect the location of the generation of .pyc files to other than that of the corresponding .py files? Regards, Swapnil

5 4

Announcing PEP 3136
by Hatem Nassrat 07 Oct '09

07 Oct '09

Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote: > On 6/30/07, Matt Chisholm <matt-python at theory.org> wrote: > > I've created and submitted a new PEP proposing support for labels in > > Python's break and continue statements. Georg Brandl has graciously > > added it to the PEP list as PEP 3136: > > > > http://www.python.org/dev/peps/pep-3136/ > > I think this is a good summary of various proposals that have been > floated in the past, plus some new ones. As a PEP, it falls short > because it doesn't pick a solution but merely offers a large menu of > possible options. Also, there is nothing about implementation yet. > > However, I'm rejecting it on the basis that code so complicated to > require this feature is very rare. In most cases there are existing > work-arounds that produce clean code, for example using 'return'. I agree that this feature will only serve as a quick hack and in many cases it would be misused and ugly code will be the result. However, it seems that there are some shortcuts that have sneaked into python (I am a fairly new Python programmer, only since late 2.4, so don't shoot me). The specific one of which I speak about is: while_stmt ::= "while" expression ":" suite ["else" ":" suite] for_stmt ::= "for" target_list "in" expression_list ":" suite ["else" ":" suite] try1_stmt ::= "try" ":" suite ("except" [expression ["as" target]] ":" suite)+ ["else" ":" suite] ["finally" ":" suite] All these else's seem like shortcuts to me. I did find a use for them, once I found out they existed, but I get butterflies whenever I do. -- Hatem Nassrat

7 7

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
by P.J. Eby 06 Oct '09

06 Oct '09

At 07:00 PM 9/23/2009 +0200, Tarek Ziadé wrote: >While it's great to have Philipp being part of our distutils design >discussions, >for his experience, I am not concerned of not having him in this "internal >consensus" since Setuptools is not maintained anymore. > >He said some months ago, he would work on a brand new setuptools >version with zero >dependency to distutils. But it's still vaporware (from his own >words), and the previous version is unmaintained for a year, so it was >forked. Here's what actually happened, if anyone cares. Tarek and friends announced a fork of setuptools. I reviewed the work and saw that -- for the most part -- I was happy with it, and opined as how I might be willing to bless the the "package inquisition" team as official maintainers of the 0.6 branch of setuptools, so that I could work on the fun bits I've long planned for 0.7, but never felt free to start on while there was so much still needing to be done on 0.6. However, just as I mentioned this, and suggested an option for what I could do that would be helpful to his Distribute 0.7 project as well as various other tools (e.g. implementing some of Jim Fulton's long-requested features for better modularization of setuptools), Tarek accused me of somehow trying to undermine his plans. In addition, it appears Tarek was also offended by my earlier statement that there were only a few people in the Python community who had *already* earned my implicit trust to not only hack on setuptools unsupervised, but also to take over its *future* direction and BDFL-ship. (For example, Jim Fulton and Ian Bicking.) Tarek, however, appears to have taken this to mean that I personally thought he was an incompetent programmer or something (when I actually had no opinion one way or the other), and ever since he has taken to levelling potshots like the above at me on a semi-regular basis. I've tried to ignore this and play nice, because he is actually working on this stuff and I am not. But it's hard for me to actually give any help in practice, if Tarek is too busy projecting hidden plots onto everything I say and do. If you read Tarek's distutils-sig posts, it appears my already-existing trust in Ian and Jim was not only a personal insult to Tarek, but also a plot to ensure that nobody with any time to do so would ever work on setuptools, just as my excitement about working on setuptools again was a plot to steal thunder from his fork. All I want is for good stuff to happen for setuptools users and Python users in general, so I don't think all the suspicion and backbiting is merited. I certainly don't appreciate it, and I would like it to stop. It also isn't even relevant to the thread, since my lack of work on setuptools says exactly zero about the merits or lack thereof of Tarek's proposals for the distutils! Hell, I *support* the bulk of Tarek's setup.cfg proposal, and don't even object to him Pronouncing it or cutting off the discussion! My only issue on Python-Dev was his inaccurate implication that it was a SIG consensus rather than a pronouncement on it. There is and was no need for any of this to get personal, and I have continually strived to keep my posts here and distutils-sig civil, even when I didn't feel like being civil in response to Tarek's jabs. I have in fact bent over backwards to be *nice* to Tarek, because he seemed so damn sensitive about everything. Apparently, however, this does not actually help things. :-(

7 8

Old libc's isspace() bug on FreeBSD brings back on Mac OS X?
by INADA Naoki 06 Oct '09

06 Oct '09

I found this hg's issue. http://mercurial.selenic.com/bts/msg8375 I think below fix is not enabled on Mac OS X. http://svn.python.org/view/python/trunk/Include/pyport.h?view=diff&pathrev=… I can't confirm it because I am not Mac OS X user. Can anyone confirm it? -- Naoki INADA <songofacandy(a)gmail.com>

3 6

eggs now mandatory for pypi?
by Fredrik Lundh 06 Oct '09

06 Oct '09

it's revews like this that makes me wonder if releasing open source is a good idea: no egg - worst seen ever, remove it from pypi or provide an egg (jensens, 2009-10-05, 0 points) </F>

17 31

Re: [Python-Dev] Package install failures in 2.6.3
by P.J. Eby 06 Oct '09

06 Oct '09

At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote: >Setuptools development has been discontinued for a year, and does >patches on Distutils code. Some of these patches are sensitive to any change >made on Distutils, wether those changes are internal or not. Setuptools is also not the only thing out there that subclasses distutils commands in general, or the build_ext command in particular. Numpy, Twisted, the mx extensions... there are plenty of things out there that subclass distutils commands, quite in adherence to the rules. (Note too that subclassing != patching, and the ability to subclass and substitute distutils commands is documented.) It's therefore not appropriate to treat the issue as if it were setuptools-specific; it could have broken any other major (or minor) package's subclassing of the build_ext command.

2 1

Help needed for tar archive creation with changed UID/GID
by bheemesh v 06 Oct '09

06 Oct '09

Hello, I am a newbie to this mailing list, i have seen in some mail discussions about a tar archive creation by forcibly setting the UID/GID to a specific user (say root). Te code mentioned goes like this: tar = tarfile.open("foo.tar.gz", "w:gz") for filename in filenames: tarinfo = tar.gettarinfo(filename) if tarinfo.isreg(): fobj = open(filename) else: fobj = None tarinfo.uid = 0 tarinfo.gid = 0 tar.addfile(tarinfo, fobj) tar.close() But this is not really working for me as when i am trying to un-tar or un-compress contents to a new directory and contents still have diff GID & UID in the long listing of directory. Can somebody suggest an alternative or a working case if already changes are done here. Thanks in advance. Best regards, Bheemesh

3 2

summary of transitioning from % to {} formatting
by Steven Bethard 06 Oct '09

06 Oct '09

I thought it might be useful for those who don't have time to read a million posts to have a summary of what's happened in the formatting discussion. The basic problem is that many APIs in the standard library and elsewhere support only %-formatting and not {}-formatting, e.g. logging.Formatter accepts:: logging.Formatter(fmt="%(asctime)s - %(name)s") but not:: logging.Formatter(fmt="{asctime} - {name}") There seems to be mostly agreement that these APIs should at least support both formatting styles, and a sizable group (including Guido) believe that %-formatting should eventually be phased out (e.g. by Python 4). There are a number of competing proposals on how to allow such APIs to start accepting {}-format strings: * Add a parameter which declares the type of format string:: logging.Formatter(fmt="{asctime} - {name}", format=BRACES) The API code would then switch between %-format and {}-format based on the value of that parameter. If %-formatting is to be deprecated, this could be done by first deprecating format=PERCENTS and requiring format=BRACES, and then changing the default to format=BRACES. * Create string subclasses which convert % use to .format calls:: __ = brace_fmt logging.Formatter(fmt=__("{asctime} - {name}")) The API code wouldn't have to change at all at first, as applying % to brace_fmt objects would call .format() instead. If %-formatting is to be deprecated, this could be done by first deprecating plain strings and requiring brace_fmt strings, and then allowing plain strings again but assuming they are {}-format strings. * Teach the API to accept callables as well as strings:: logging.Formatter(fmt="{asctime} - {name}".format) The API code would just call the object with .format() style arguments if a callable was given instead of a string. If %-formatting is to be deprecated, this could be done by first deprecating plain strings and requiring callables, and then allowing plain strings again but assuming they are {}-format strings * Create translators between %-format and {}-format:: assert to_braces("%(asctime)s") == "{asctime}" assert to_percents("{asctime}") == "%(asctime)s" these could then either be used outside of the API:: logging.Formatter(fmt=to_percents("{asctime} - {name}")) or they could be used within the API combined with some sort of heuristic for guessing whether a {}-format string or a %-format string was passed in:: logging.Formatter(fmt="{asctime} - {name}") If %-formatting is to be deprecated, the transition strategy here is trivial. However, no one has yet written translators, and it is not clear what heuristics should be used, e.g. should the method just try %-formatting first and then {}-formatting if it fails? I don't think there is consensus yet on which of these proposals should be the "blessed" one. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

12 23

Re: [Python-Dev] Package install failures in 2.6.3
by P.J. Eby 05 Oct '09

05 Oct '09

At 11:21 AM 10/5/2009 -0700, Brett Cannon wrote: >I have to admit I find it really disheartening that we are letting >an unmaintained project dictate how we fix a bug. Setuptools was not the only project broken by this change. See: http://bugs.python.org/issue7020#msg93355 Apparently, I'm not the only person who read the get_ext_filename() docstring that way, and subclassed build_ext in a way that broke it. (In this case, it was pywin32.) IMO, the fact that it broke Pywin32 in 2.6.3rc1 should have been considered evidence that the change was not suitable for a bugfix release.

1 0

Re: [Python-Dev] Package install failures in 2.6.3
by P.J. Eby 05 Oct '09

05 Oct '09

At 04:17 PM 10/5/2009 +0200, Tarek Ziadé wrote: >Now I am astonished that we are talking about reverting changes in >Distutils that were done for bugfixes, for a third party package that >does monkey patches on Distutils. Subclassing is not monkeypatching, so if you consider the above to be a general policy, then the developers of at least Numpy and Twisted should consider themselves warned that bugfix releases may break their build processes.

1 0

Python 2.6.3rc1 available
by Barry Warsaw 04 Oct '09

04 Oct '09

The first (and hopefully last) release candidate for Python 2.6.3 is now available via http://www.python.org/download/releases/2.6.3/ Source releases and Windows binaries are currently available, and Mac OS X binaries should be forthcoming. Nearly 100 bugs have been fixed since 2.6.2. Barring any unforeseen problems, we will make the final 2.6.3 release this Friday, October 2nd. Please give this release candidate a spin and let us know if you encounter any show stopping problems. Enjoy, -Barry

4 3

% to .format() converter
by Benjamin Peterson 03 Oct '09

03 Oct '09

Interested in the recent threads about % and str.format(), I wrote a little Python 3 script that converts % format strings to format strings compatible with str.format(). I invite you to try it out. The code is at https://code.launchpad.net/~gutworth/+junk/mod2format (That means you can do "bzr branch lp:~gutworth/+junk/mod2format".) It should basically work except for some obscure cases like "%#.0f". -- Regards, Benjamin

1 0

PEP 3144 review.
by Peter Moody 03 Oct '09

03 Oct '09

Folks, Guido, I believe PEP 3144 is ready for your review. When you get a chance, can you take a look/make a pronouncement? Cheers, /peter

35 266

PEP 3121
by Andrew Svetlov 03 Oct '09

03 Oct '09

What real status of this document? As I figured out py3k trunk uses this ones. Most part of 'battery included' modules don't use this feature, leaving m_traverse, m_clear and m_free NULL pointers. There are only exception: _io. But looks like all underground python machinery is already ported to support PEP. Maybe it's good point to update PEP? "accepted; may not be implemented yet" sounds a bit confusing. Just insert somethere close to top of content: "Implemented by Python itself, but builtin modules should be converted". Next question: are where all 'python standard library' modules looks like "not converted yet" really need to be refactored? Or we can split this huge set to 'looks already good' and 'requires some work'? And just add comment for every PyModuleDef definition like: "Completely satisfy PEP 3121, signed and stamped by Martin von Loewis and GvR".? Last question: PEP refers to "multiple interpreters" feature of python. This feature presented at least in 2.xx branch (don't remember about 1.xx - up to 2003 I used python as scripting language only and not care about C interface). I never saw usage of this one in real use cases. Is there projects (preferable with code sources, of course) what runs multiple interpreter in same process?

2 1

RELEASED Python 2.6.3
by Barry Warsaw 02 Oct '09

02 Oct '09

On behalf of the Python community, I'm happy to announce the availability of Python 2.6.3. This is the latest production-ready version in the Python 2.6 series. Somewhere near 100 bugs have been fixed since Python 2.6.2 was released in April 2009. Please see the NEWS file for all the gory details. http://www.python.org/download/releases/2.6.3/NEWS.txt Source tarballs, Windows installers and the Mac OS X disk image can be downloaded from the Python 2.6.3 page. http://www.python.org/download/releases/2.6.3/ For more information on Python 2.6 in general, please see http://docs.python.org/whatsnew/2.6.html Please report bugs for any Python version in the Python tracker. http://bugs.python.org Enjoy, -Barry Barry Warsaw barry(a)python.org Python 2.6 Release Manager (on behalf of the entire python-dev team)

1 0

Re: [Python-Dev] Announcing PEP 3136
by Karen Tracey 02 Oct '09

02 Oct '09

At 05:15 PM 9/30/2009, Yuvgoog Greenle wrote: >I like how python has a minimalistic and powerful syntax (-1 for the >break ___ PEP). > >Also, I really dislike the for/else ambiguity "butterflies". > >When is the else after a loop executed? >1. When the loop isn't entered at all. >2. When the loop terminates through exhaustion of the list (does >this include when the list was empty?) >3. When the loop didn't exit because of a break statement. > >HINTS: The way django does it is opposite the way python does it and >there may be more than one correct answer. Django's template language does not have for/else, it has for/empty: <http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty>http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty This construct did come from an external snippet that used 'else' instead of 'empty'. However when it was integrated into Django the 'else' name was specifically rejected because it did the opposite of what for/else does in Python. Karen

1 0

Summary of Python tracker Issues
by Python tracker 02 Oct '09

02 Oct '09

ACTIVITY SUMMARY (09/25/09 - 10/02/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2410 open (+17) / 16447 closed (+24) / 18857 total (+41) Open issues with patches: 958 Average duration of open issues: 673 days. Median duration of open issues: 430 days. Open Issues Breakdown open 2376 (+17) pending 33 ( +0) Issues Created Or Reopened (44) _______________________________ Mismatching use of memory APIs 09/28/09 CLOSED http://bugs.python.org/issue6836 reopened r.david.murray patch threading.local subclasses don't cleanup their state and it gets 09/29/09 CLOSED http://bugs.python.org/issue6990 reopened pitrou patch, needs review PEP 314 inconsistency (authors/author/maintainer) 09/28/09 http://bugs.python.org/issue6992 reopened techtonik Python 3.1 interpreter Fatal Error on windows with unknown encod 09/25/09 CLOSED http://bugs.python.org/issue6995 created bahaelaila7 Python 2.6.2 & 3.1.1 Installer 09/25/09 CLOSED http://bugs.python.org/issue6996 created deepakp python26 compiled on snow leopard x86_64 09/25/09 CLOSED http://bugs.python.org/issue6997 created monway Bug in Tutorial (introduction.rst) 09/25/09 CLOSED http://bugs.python.org/issue6998 created cofi TypeError in pathfix.py 09/25/09 CLOSED http://bugs.python.org/issue6999 created amcnabb patch optional second argument of string.capwords not documented 09/25/09 CLOSED http://bugs.python.org/issue7000 created MLModel turtle.py bug-fixes, backported from 3.1 [issue5923] 09/25/09 CLOSED http://bugs.python.org/issue7001 created gregorlingl patch help me to set variables - 64 bit 09/26/09 CLOSED http://bugs.python.org/issue7002 created ashish finish documentation of user local paths 09/26/09 http://bugs.python.org/issue7003 created benjamin.peterson Py_RETURN_BOOL() convenience macro 09/27/09 CLOSED http://bugs.python.org/issue7004 created jon patch ConfigParser does not handle options without values 09/27/09 http://bugs.python.org/issue7005 created mkindahl patch The replacement suggested for callable(x) in py3k is not equival 09/27/09 http://bugs.python.org/issue7006 created milko.krachounov Tiny inconsistency in the orthography of "url encoded" in the do 09/27/09 http://bugs.python.org/issue7007 created MLModel str.title() misbehaves with apostrophes 09/27/09 CLOSED http://bugs.python.org/issue7008 created nickd random.randint docs 09/28/09 CLOSED http://bugs.python.org/issue7009 created jgsack Rounding when converting float tuple to str 09/28/09 CLOSED http://bugs.python.org/issue7010 created scientist47 tarinfo has problems with longlinks 09/28/09 CLOSED http://bugs.python.org/issue7011 created do3cc Tabs is better than spaces for indentation 09/28/09 CLOSED http://bugs.python.org/issue7012 created rohdef Httplib read routine is not tolerant to not well-formed chunked 09/28/09 http://bugs.python.org/issue7013 created Andrei Korostelev patch Logging incompatible with IronPython 09/28/09 CLOSED http://bugs.python.org/issue7014 created michael.foord Getting call trace while executing "modules spam" at help prompt 09/29/09 http://bugs.python.org/issue7015 created rishikesh patch .pyc files are set executable if the .py file is too 09/29/09 CLOSED http://bugs.python.org/issue7016 created stevenjd os.listdir behaviour 09/29/09 CLOSED http://bugs.python.org/issue7017 created bigaddo Recommend "*" over "#" in getargs.c typecodes 09/29/09 http://bugs.python.org/issue7018 created pitrou unmarshaling of artificial strings can produce funny longs. 09/29/09 http://bugs.python.org/issue7019 created cfbolz patch regression in pywin32 build due to 2.6.3rc1 09/30/09 CLOSED http://bugs.python.org/issue7020 created srid subprocess.Popen doesn't work without "executable=" 09/30/09 CLOSED http://bugs.python.org/issue7021 created hc Doc update for io module 09/30/09 CLOSED http://bugs.python.org/issue7022 created pakal Marshal doesn't release GIL while dumping 09/30/09 CLOSED http://bugs.python.org/issue7023 created zengke patch webbrowser : Could not open ftp server using webbrowser.open() 09/30/09 http://bugs.python.org/issue7024 created hmo Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0 09/30/09 CLOSED http://bugs.python.org/issue7025 created jon test_urllib: unsetting missing 'env' variable 10/01/09 http://bugs.python.org/issue7026 created srid test_io.py: codecs.IncrementalDecoder is sometimes None 10/01/09 http://bugs.python.org/issue7027 created srid Add int.hex for symmetry with float.hex 10/02/09 http://bugs.python.org/issue7028 reopened mark.dickinson Improve pybench 10/01/09 http://bugs.python.org/issue7029 created krisvale patch Update version{added,changed} entries in py3k unittest docs 10/01/09 http://bugs.python.org/issue7030 created mark.dickinson add assertIsInstance 10/01/09 CLOSED http://bugs.python.org/issue7031 created georg.brandl patch, patch, easy, needs review Make assertMultilineEqual default for unicode string comparison 10/01/09 http://bugs.python.org/issue7032 created michael.foord C/API - Document exceptions 10/02/09 http://bugs.python.org/issue7033 created lekma While Loop Bug on a game of 21, help! 10/02/09 CLOSED http://bugs.python.org/issue7034 created PixelHead777 codecs error handlers lack documentation 10/02/09 http://bugs.python.org/issue7035 created olau Issues Now Closed (42) ______________________ Subprocess error with I/O redirection to Pipes 341 days http://bugs.python.org/issue4192 pakal os.popen2 and os.popen3 in python 2.6 incompatible with os.popen 221 days http://bugs.python.org/issue5329 pjenvey patch Python 3.0 grammar is ambiguous with the addition of star_expr 201 days http://bugs.python.org/issue5460 benjamin.peterson http://docs.python.org/dev/library/unittest.html#load-tests-prot 71 days http://bugs.python.org/issue6515 michael.foord csv.Sniffer.sniff on data with doublequotes doesn't set up the d 60 days http://bugs.python.org/issue6606 jtate patch Integer & Long types: Performance improvement of 1.6x to 2x for 42 days http://bugs.python.org/issue6713 mark.dickinson patch httplib and array do not play together well 33 days http://bugs.python.org/issue6790 pitrou patch, easy Mismatching use of memory APIs 0 days http://bugs.python.org/issue6836 krisvale patch Test creation in unittest.TestProgram should be done in one plac 6 days http://bugs.python.org/issue6956 michael.foord Extension modules fail to build on OS X 10.6 using python.org 2. 8 days http://bugs.python.org/issue6957 ronaldoussoren Add Python command line flags to configure logging 10 days http://bugs.python.org/issue6958 vinay.sajip patch numpy extensions to distutils... are a source of improvements fo 3 days http://bugs.python.org/issue6968 tjreedy Add the SIO_KEEPALIVE_VALS option to socket.ioctl 5 days http://bugs.python.org/issue6971 krisvale patch, patch, easy Compile error for Python-2.6.2 on Solaris 1 days http://bugs.python.org/issue6989 ashish threading.local subclasses don't cleanup their state and it gets 0 days http://bugs.python.org/issue6990 pitrou patch, needs review logging encoding failes some situation 1 days http://bugs.python.org/issue6991 naoki patch importing of "time" module is terribly slow 0 days http://bugs.python.org/issue6993 ndyankov enumerate dosctring has a typo 0 days http://bugs.python.org/issue6994 ezio.melotti Python 3.1 interpreter Fatal Error on windows with unknown encod 0 days http://bugs.python.org/issue6995 r.david.murray Python 2.6.2 & 3.1.1 Installer 0 days http://bugs.python.org/issue6996 deepakp python26 compiled on snow leopard x86_64 0 days http://bugs.python.org/issue6997 monway Bug in Tutorial (introduction.rst) 0 days http://bugs.python.org/issue6998 ezio.melotti TypeError in pathfix.py 0 days http://bugs.python.org/issue6999 benjamin.peterson patch optional second argument of string.capwords not documented 1 days http://bugs.python.org/issue7000 ezio.melotti turtle.py bug-fixes, backported from 3.1 [issue5923] 3 days http://bugs.python.org/issue7001 r.david.murray patch help me to set variables - 64 bit 0 days http://bugs.python.org/issue7002 brett.cannon Py_RETURN_BOOL() convenience macro 1 days http://bugs.python.org/issue7004 jon patch str.title() misbehaves with apostrophes 2 days http://bugs.python.org/issue7008 gvanrossum random.randint docs 0 days http://bugs.python.org/issue7009 orsenthil Rounding when converting float tuple to str 0 days http://bugs.python.org/issue7010 rhettinger tarinfo has problems with longlinks 0 days http://bugs.python.org/issue7011 do3cc Tabs is better than spaces for indentation 1 days http://bugs.python.org/issue7012 gvanrossum Logging incompatible with IronPython 1 days http://bugs.python.org/issue7014 michael.foord .pyc files are set executable if the .py file is too 0 days http://bugs.python.org/issue7016 r.david.murray os.listdir behaviour 1 days http://bugs.python.org/issue7017 bigaddo regression in pywin32 build due to 2.6.3rc1 2 days http://bugs.python.org/issue7020 srid subprocess.Popen doesn't work without "executable=" 0 days http://bugs.python.org/issue7021 hc Doc update for io module 1 days http://bugs.python.org/issue7022 pitrou Marshal doesn't release GIL while dumping 0 days http://bugs.python.org/issue7023 benjamin.peterson patch Python 3.1 and 3.2 (dev) opensearch.xml still references 3.0 0 days http://bugs.python.org/issue7025 benjamin.peterson add assertIsInstance 0 days http://bugs.python.org/issue7031 georg.brandl patch, patch, easy, needs review While Loop Bug on a game of 21, help! 0 days http://bugs.python.org/issue7034 PixelHead777 Top Issues Most Discussed (10) ______________________________ 27 str.title() misbehaves with apostrophes 2 days closed http://bugs.python.org/issue7008 27 PEP 314 inconsistency (authors/author/maintainer) 4 days open http://bugs.python.org/issue6992 23 zipfile.ZipFile overwrites files outside destination path 10 days open http://bugs.python.org/issue6972 14 no longer possible to hash arrays 135 days open http://bugs.python.org/issue6071 11 ssl.SSLSocket.recv() implementation may not work with non-block 380 days open http://bugs.python.org/issue3890 10 regression in pywin32 build due to 2.6.3rc1 2 days closed http://bugs.python.org/issue7020 9 unmarshaling of artificial strings can produce funny longs. 3 days open http://bugs.python.org/issue7019 9 httplib and array do not play together well 33 days closed http://bugs.python.org/issue6790 7 Add int.hex for symmetry with float.hex 0 days open http://bugs.python.org/issue7028 6 threading.local subclasses don't cleanup their state and it get 0 days closed http://bugs.python.org/issue6990

1 0

Python 2.6.3
by Barry Warsaw 01 Oct '09

01 Oct '09

I had previously wanted to release Python 2.6.3 over the summer, but for various personal reasons, the summer was just too insane. I'd like to reschedule a 2.6.3 release, shooting for final release on 25- September. We should probably do a release candidate, so I'd like to make that on 23-September. Does anybody have objections to that schedule? If not, I'll try to spend some time over the next few days looking at outstanding bugs, and marking release blockers, etc. -Barry

14 35