Mailman 3 October 2009 - Python-Dev

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

16 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 16 Oct '09

16 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 14 Oct '09

14 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 13 Oct '09

13 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 12 Oct '09

12 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