Mailman 3 April 2010 - Python-Dev

http://bugs.python.org/ is down
by Victor Stinner 17 Apr '10

17 Apr '10

Hi, http://bugs.python.org/ displays "Service Temporarily Unavailable". Is it normal? -- Victor Stinner http://www.haypocalc.com/

3 2

OS information, tags
by Anand Balachandran Pillai 17 Apr '10

17 Apr '10

Hi, I am surprised to see that the bug-tracker doesn't have an OS classifier or ability to add tags ? Since a number of issues reported seem to be OS specific (one can find a lot of Windows only issues upon a search), won't adding these fields help bug triaging ? I am not sure which software is being used by bug tracker so excuse me if this has been already discussed in this form. A quick search in my gmail archives yielded no such discussion. Thanks, -- --Anand

11 19

PEP 3147 ready for pronouncement and merging
by Barry Warsaw 17 Apr '10

17 Apr '10

I am attaching the latest revision of PEP 3147 to this message, which is also available here: http://www.python.org/dev/peps/pep-3147/ I think the PEP is ready for pronouncement, and the patch is pretty much ready for merging into py3k. The only thing that I can think of that is not implemented yet is this section on PEP 302 loaders: PEP 302 [18]_ defined loaders have a `.get_filename()` method which points to the `__file__` for a module. As part of this PEP, we will extend this API, to include a new method `.get_paths()` which will return a 2-tuple containing the path to the source file and the path to where the matching `pyc` file is (or would be). I'm honestly not sure whether this is still essential, or whether the importlib ABC changes Brett and I talked about at Pycon are still required. I now believe they are at best a minor part of the implementation if so. Maybe Brett can chime in on that. Everything else is implemented, tested, and has undergone four rounds of Rietveld reviews (thanks Antoine, Benjamin, Brett, and Georg!). A fifth patch set has been uploaded and is available here: http://codereview.appspot.com/842043/show This addresses all previous comments, includes some fixes from Brian Curtin for Windows (thanks!) and fixes __main__ and -m support. I'd like to commit this to py3k sooner rather than later so that we can shake out any additional issues that might crop up, without having to continue to maintain my external branches. Guido, what say you? -Barry PEP: 3147 Title: PYC Repository Directories Version: $Revision: 80025 $ Last-Modified: $Date: 2010-04-12 22:17:40 -0400 (Mon, 12 Apr 2010) $ Author: Barry Warsaw <barry(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2009-12-16 Python-Version: 3.2 Post-History: 2010-01-30, 2010-02-25, 2010-03-03, 2010-04-12 Abstract ======== This PEP describes an extension to Python's import mechanism which improves sharing of Python source code files among multiple installed different versions of the Python interpreter. It does this by allowing more than one byte compilation file (.pyc files) to be co-located with the Python source file (.py file). The extension described here can also be used to support different Python compilation caches, such as JIT output that may be produced by an Unladen Swallow [1]_ enabled C Python. Background ========== CPython compiles its source code into "byte code", and for performance reasons, it caches this byte code on the file system whenever the source file has changes. This makes loading of Python modules much faster because the compilation phase can be bypassed. When your source file is `foo.py`, CPython caches the byte code in a `foo.pyc` file right next to the source. Byte code files contain two 32-bit numbers followed by the marshaled [2]_ code object. The 32-bit numbers represent a magic number and a timestamp. The magic number changes whenever Python changes the byte code format, e.g. by adding new byte codes to its virtual machine. This ensures that pyc files built for previous versions of the VM won't cause problems. The timestamp is used to make sure that the pyc file is not older than the py file that was used to create it. When either the magic number or timestamp do not match, the py file is recompiled and a new pyc file is written. In practice, it is well known that pyc files are not compatible across Python major releases. A reading of import.c [3]_ in the Python source code proves that within recent memory, every new CPython major release has bumped the pyc magic number. Rationale ========= Linux distributions such as Ubuntu [4]_ and Debian [5]_ provide more than one Python version at the same time to their users. For example, Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1, with Python 2.6 being the default. This causes a conflict for Python source files installed by the system (including third party packages), because you cannot compile a single Python source file for more than one Python version at a time. Thus if your system wanted to install a `/usr/share/python/foo.py`, it could not create a `/usr/share/python/foo.pyc` file usable across all installed Python versions. Furthermore, in order to ease the burden on operating system packagers for these distributions, the distribution packages do not contain Python version numbers [6]_; they are shared across all Python versions installed on the system. Putting Python version numbers in the packages would be a maintenance nightmare, since all the packages - *and their dependencies* - would have to be updated every time a new Python release was added or removed from the distribution. Because of the sheer number of packages available, this amount of work is infeasible. C extensions can be source compatible across multiple versions of Python. Compiled extension modules are usually not compatible though, and PEP 384 [7]_ has been proposed to address this by defining a stable ABI for extension modules. Because these distributions cannot share pyc files, elaborate mechanisms have been developed to put the resulting pyc files in non-shared locations while the source code is still shared. Examples include the symlink-based Debian regimes python-support [8]_ and python-central [9]_. These approaches make for much more complicated, fragile, inscrutable, and fragmented policies for delivering Python applications to a wide range of users. Arguably more users get Python from their operating system vendor than from upstream tarballs. Thus, solving this pyc sharing problem for CPython is a high priority for such vendors. This PEP proposes a solution to this problem. Proposal ======== Python's import machinery is extended to write and search for byte code cache files in a single directory inside every Python package directory. This directory will be called `__pycache__`. Further, pyc files will contain a magic string that differentiates the Python version they were compiled for. This allows multiple byte compiled cache files to co-exist for a single Python source file. This scheme has the added benefit of reducing the clutter in a Python package directory. When a Python source file is imported for the first time, a `__pycache__` directory will be created in the package directory, if one does not already exist. The pyc file for the imported source will be written to the `__pycache__` directory, using the magic-tag formatted name. If either the creation of the `__pycache__` directory or the pyc file inside that fails, the import will still succeed, just as it does in a pre-PEP-3147 world. If the py source file is missing, the pyc file inside `__pycache__` will be ignored. This eliminates the problem of accidental stale pyc file imports. For backward compatibility, Python will still support pyc-only distributions, however it will only do so when the pyc file lives in the directory where the py file *would* have been, i.e. not in the `__pycache__` directory. pyc file outside of `__pycache__` will only be imported if the py source file is missing. Tools such as `py_compile` [15]_ and `compileall` [16]_ will be extended to create PEP 3147 formatted layouts automatically, but will have an option to create pyc-only distribution layouts. Examples --------- What would this look like in practice? Let's say we have a Python package named `alpha` which contains a sub-package name `beta`. The source directory layout before byte compilation might look like this:: alpha/ __init__.py one.py two.py beta/ __init__.py three.py four.py After byte compiling this package with Python 3.2, you would see the following layout:: alpha/ __pycache__/ __init__.cpython-32.pyc one.cpython-32.pyc two.cpython-32.pyc __init__.py one.py two.py beta/ __pycache__/ __init__.cpython-32.pyc three.cpython-32.pyc four.cpython-32.pyc __init__.py three.py four.py *Note: listing order may differ depending on the platform.* Let's say that two new versions of Python are installed, one is Python 3.3 and another is Unladen Swallow. After byte compilation, the file system would look like this:: alpha/ __pycache__/ __init__.cpython-32.pyc __init__.cpython-33.pyc __init__.unladen-10.pyc one.cpython-32.pyc one.cpython-33.pyc one.unladen-10.pyc two.cpython-32.pyc two.cpython-33.pyc two.unladen-10.pyc __init__.py one.py two.py beta/ __pycache__/ __init__.cpython-32.pyc __init__.cpython-33.pyc __init__.unladen-10.pyc three.cpython-32.pyc three.cpython-33.pyc three.unladen-10.pyc four.cpython-32.pyc four.cpython-33.pyc four.unladen-10.pyc __init__.py three.py four.py As you can see, as long as the Python version identifier string is unique, any number of pyc files can co-exist. These identifier strings are described in more detail below. A nice property of this layout is that the `__pycache__` directories can generally be ignored, such that a normal directory listing would show something like this:: alpha/ __pycache__/ __init__.py one.py two.py beta/ __pycache__/ __init__.py three.py four.py This is much less cluttered than even today's Python. Python behavior =============== When Python searches for a module to import (say `foo`), it may find one of several situations. As per current Python rules, the term "matching pyc" means that the magic number matches the current interpreter's magic number, and the source file is not newer than the `pyc` file. Case 1: The first import ------------------------ When Python is asked to import module `foo`, it searches for a `foo.py` file (or `foo` package, but that's not important for this discussion) along its `sys.path`. When Python locates the `foo.py` file it will look for a `__pycache__` directory in the directory where it found the `foo.py`. If the `__pycache__` directory is missing, Python will create it. Then it will parse and byte compile the `foo.py` file and save the byte code in `__pycache__/foo.<magic>.pyc`, where <magic> is defined by the Python implementation, but will be a human readable string such as `cpython-32`. Case 2: The second import ------------------------- When Python is asked to import module `foo` a second time (in a different process of course), it will again search for the `foo.py` file along its `sys.path`. When Python locates the `foo.py` file, it looks for a matching `__pycache__/foo.<magic>.pyc` and finding this, it reads the byte code and continues as usual. Case 3: __pycache__/foo.<magic>.pyc with no source --------------------------------------------------- It's possible that the `foo.py` file somehow got removed, while leaving the cached pyc file still on the file system. If the `__pycache__/foo.<magic>.pyc` file exists, but the `foo.py` file used to create it does not, Python will raise an `ImportError` when asked to import foo. In other words, Python will not import a pyc file from the cache directory unless the source file exists. Case 4: legacy pyc files and source-less imports ------------------------------------------------ Python will ignore all legacy pyc files when a source file exists next to it. In other words, if a `foo.pyc` file exists next to the `foo.py` file, the pyc file will be ignored in all cases In order to continue to support source-less distributions though, if the source file is missing, Python will import a lone pyc file if it lives where the source file would have been. Case 5: read-only file systems ------------------------------ When the source lives on a read-only file system, or the `__pycache__` directory or pyc file cannot otherwise be written, all the same rules apply. This is also the case when `__pycache__` happens to be written with permissions which do not allow for writing containing pyc files. Flow chart ========== Here is a flow chart describing how modules are loaded: .. image:: pep-3147-1.png :scale: 75 Magic identifiers ================= pyc files inside of the `__pycache__` directories contain a magic identifier in their file names. These are mnemonic tags for the actual magic numbers used by the importer. For example, in Python 3.2, we could use the hexlified [10]_ magic number as a unique identifier:: >>> from binascii import hexlify >>> from imp import get_magic >>> 'foo.{}.pyc'.format(hexlify(get_magic()).decode('ascii')) 'foo.580c0d0a.pyc' This isn't particularly human friendly though. Instead, this PEP proposes a *magic tag* that uniquely defines `.pyc` files for the current version of Python. Whenever the magic number is bumped, a new magic tag is defined which is unique among all versions and implementations of Python. The actual contents of the magic tag is left up to the implementation, although it is recommended that the tag include the implementation name and a version shorthand. In general, magic numbers never change between Python micro releases, but the convention can be extended to handle magic number changes between pre-release development versions. For example, CPython 3.2 would have a magic tag of `cpython-32` and write pyc files like this: `foo.cpython-32.pyc`. When the `-O` flag is used, it would write `foo.cpython-32.pyo`. For backports of this feature to Python 2, when the `-U` flag is used, a file such as `foo.cpython-27u.pyc` can be written. The magic tag is available in the `imp` module via the `get_tag()` function. This is analogous to the `get_magic()` function already available in that module. Alternative Python implementations ================================== Alternative Python implementations such as Jython [11]_, IronPython [12]_, PyPy [13]_, Pynie [14]_, and Unladen Swallow can also use the `__pycache__` directory to store whatever compilation artifacts make sense for their platforms. For example, Jython could store the class file for the module in `__pycache__/foo.jython-32.class`. Implementation strategy ======================= This feature is targeted for Python 3.2, solving the problem for those and all future versions. It may be back-ported to Python 2.7. Vendors are free to backport the changes to earlier distributions as they see fit. Effects on existing code ======================== Adoption of this PEP will affect existing code and idioms, both inside Python and outside. This section enumerates some of these effects. __file__ --------- In Python 3, when you import a module, its `__file__` attribute points to its source `py` file (in Python 2, it points to the `pyc` file). A package's `__file__` points to the `py` file for its `__init__.py`. E.g.:: >>> import foo >>> foo.__file__ 'foo.py' # baz is a package >>> import baz >>> baz.__file__ 'baz/__init__.py' Nothing in this PEP would change the semantics of `__file__`. This PEP proposes the addition of an `__cached__` attribute to modules, which will always point to the actual `pyc` file that was read or written. When the environment variable `$PYTHONDONTWRITEBYTECODE` is set, or the `-B` option is given, or if the source lives on a read-only filesystem, then the `__cached__` attribute will point to the location that the `pyc` file *would* have been written to if it didn't exist. This location of course includes the `__pycache__` subdirectory in its path. For alternative Python implementations which do not support `pyc` files, the `__cached__` attribute may point to whatever information makes sense. E.g. on Jython, this might be the `.class` file for the module: `__pycache__/foo.jython-32.class`. Some implementations may use multiple compiled files to create the module, in which case `__cached__` may be a tuple. The exact contents of `__cached__` are Python implementation specific. It is recommended that when nothing sensible can be calculated, implementations should set the `__cached__` attribute to `None`. py_compile and compileall ------------------------- Python comes with two modules, `py_compile` [15]_ and `compileall` [16]_ which support compiling Python modules external to the built-in import machinery. `py_compile` in particular has intimate knowledge of byte compilation, so these will be updated to understand the new layout. The `-b` flag is added to `compileall` for writing legacy `.pyc` byte-compiled file path names. bdist_wininst and the Windows installer --------------------------------------- These tools also compile modules explicitly on installation. If they do not use `py_compile` and `compileall`, then they would also have to be modified to understand the new layout. File extension checks --------------------- There exists some code which checks for files ending in `.pyc` and simply chops off the last character to find the matching `.py` file. This code will obviously fail once this PEP is implemented. To support this use case, we'll add two new methods to the `imp` package [17]_: * `imp.source_from_cache(py_path)` -> `pyc_path` * `imp.cache_from_source(pyc_path)` -> `py_path` Alternative implementations are free to override these functions to return reasonable values based on their own support for this PEP. PEP 302 loaders --------------- PEP 302 [18]_ defined loaders have a `.get_filename()` method which points to the `__file__` for a module. As part of this PEP, we will extend this API, to include a new method `.get_paths()` which will return a 2-tuple containing the path to the source file and the path to where the matching `pyc` file is (or would be). Backports --------- For versions of Python earlier than 3.2 (and possibly 2.7), it is possible to backport this PEP. However, in Python 3.2 (and possibly 2.7), this behavior will be turned on by default, and in fact, it will replace the old behavior. Backports will need to support the old layout by default. We suggest supporting PEP 3147 through the use of an environment variable called `$PYTHONENABLECACHEDIR` or the command line switch `-Xenablecachedir` to enable the feature. Makefiles and other dependency tools ------------------------------------ Makefiles and other tools which calculate dependencies on `.pyc` files (e.g. to byte-compile the source if the `.pyc` is missing) will have to be updated to check the new paths. Alternatives ============ PEP 304 ------- There is some overlap between the goals of this PEP and PEP 304 [19]_, which has been withdrawn. However PEP 304 would allow a user to create a shadow file system hierarchy in which to store `pyc` files. This concept of a shadow hierarchy for `pyc` files could be used to satisfy the aims of this PEP. Although the PEP 304 does not indicate why it was withdrawn, shadow directories have a number of problems. The location of the shadow `pyc` files would not be easily discovered and would depend on the proper and consistent use of the `$PYTHONBYTECODE` environment variable both by the system and by end users. There are also global implications, meaning that while the system might want to shadow `pyc` files, users might not want to, but the PEP defines only an all-or-nothing approach. As an example of the problem, a common (though fragile) Python idiom for locating data files is to do something like this:: from os import dirname, join import foo.bar data_file = join(dirname(foo.bar.__file__), 'my.dat') This would be problematic since `foo.bar.__file__` will give the location of the `pyc` file in the shadow directory, and it may not be possible to find the `my.dat` file relative to the source directory from there. Fat byte compilation files -------------------------- An earlier version of this PEP described "fat" Python byte code files. These files would contain the equivalent of multiple `pyc` files in a single `pyf` file, with a lookup table keyed off the appropriate magic number. This was an extensible file format so that the first 5 parallel Python implementations could be supported fairly efficiently, but with extension lookup tables available to scale `pyf` byte code objects as large as necessary. The fat byte compilation files were fairly complex, and inherently introduced difficult race conditions, so the current simplification of using directories was suggested. The same problem applies to using zip files as the fat pyc file format. Multiple file extensions ------------------------ The PEP author also considered an approach where multiple thin byte compiled files lived in the same place, but used different file extensions to designate the Python version. E.g. foo.pyc25, foo.pyc26, foo.pyc31 etc. This was rejected because of the clutter involved in writing so many different files. The multiple extension approach makes it more difficult (and an ongoing task) to update any tools that are dependent on the file extension. .pyc ---- A proposal was floated to call the `__pycache__` directory `.pyc` or some other dot-file name. This would have the effect on *nix systems of hiding the directory. There are many reasons why this was rejected by the BDFL [20]_ including the fact that dot-files are only special on some platforms, and we actually do *not* want to hide these completely from users. Reference implementation ======================== Work on this code is tracked in a Bazaar branch on Launchpad [22]_ until it's ready for merge into Python 3.2. The work-in-progress diff can also be viewed [23]_ and is updated automatically as new changes are uploaded. A Rietveld code review issue [24]_ has been opened as of 2010-04-01 (no, this is not an April Fools joke :). References ========== .. [1] PEP 3146 .. [2] The marshal module: http://www.python.org/doc/current/library/marshal.html .. [3] import.c: http://svn.python.org/view/python/branches/py3k/Python/import.c?view=markup .. [4] Ubuntu: <http://www.ubuntu.com> .. [5] Debian: <http://www.debian.org> .. [6] Debian Python Policy: http://www.debian.org/doc/packaging-manuals/python-policy/ .. [7] PEP 384 .. [8] python-support: http://wiki.debian.org/DebianPythonFAQ#Whatispython-support.3F .. [9] python-central: http://wiki.debian.org/DebianPythonFAQ#Whatispython-central.3F .. [10] binascii.hexlify(): http://www.python.org/doc/current/library/binascii.html#binascii.hexlify .. [11] Jython: http://www.jython.org/ .. [12] IronPython: http://ironpython.net/ .. [13] PyPy: http://codespeak.net/pypy/dist/pypy/doc/ .. [14] Pynie: http://code.google.com/p/pynie/ .. [15] py_compile: http://docs.python.org/library/py_compile.html .. [16] compileall: http://docs.python.org/library/compileall.html .. [17] imp: http://www.python.org/doc/current/library/imp.html .. [18] PEP 302 .. [19] PEP 304 .. [20] http://www.mail-archive.com/python-dev@python.org/msg45203.html .. [21] importlib: http://docs.python.org/3.1/library/importlib.html .. [22] https://code.launchpad.net/~barry/python/pep3147 .. [23] https://code.launchpad.net/~barry/python/pep3147/+merge/22648 .. [24] http://codereview.appspot.com/842043/show ACKNOWLEDGMENTS =============== Barry Warsaw's original idea was for fat Python byte code files. Martin von Loewis reviewed an early draft of the PEP and suggested the simplification to store traditional `pyc` and `pyo` files in a directory. Many other people reviewed early versions of this PEP and provided useful feedback including but not limited to: * David Malcolm * Josselin Mouette * Matthias Klose * Michael Hudson * Michael Vogt * Piotr Ożarowski * Scott Kitterman * Toshio Kuratomi Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

8 17

Re: [Python-Dev] Very Strange Argument Handling Behavior
by P.J. Eby 16 Apr '10

16 Apr '10

At 04:51 PM 4/16/2010 -0500, Benjamin Peterson wrote: >That won't work. You could put non-string keys in a dictionary and >remove them, but the dictionary would still be in the less optimized state. That only means it's slower on uncommon cases and the case where you're about to get an exception anyway.

1 0

Re: [Python-Dev] patch for review: __import__ documentation
by Brett Cannon 16 Apr '10

16 Apr '10

Yes, we have different opinions. My personal take is to wait a week before you email python-dev if there has been no activity. That is enough time for people interested in the patch to get to it as we all have different schedules. Any faster and it feels like noise on the list to me. Brett (from his phone) On Apr 14, 2010 11:28 PM, "Glyph Lefkowitz" <glyph(a)twistedmatrix.com> wrote: On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote: > I see the confusion. I think Martin meant more about open issues that required discussion, not sim... Ach. I hit 'send' too soon. I also wanted to say: it seemed quite clear to me that Martin specifically meant "simply issues that had a patch ready to go". Quoting him exactly: Please understand that setting the state of an issue to "review" may *not* be the best way to trigger a review - it may be more effective to post to python-dev if you truly believe that the patch can be committed as-is. It seems that perhaps the core developers have slightly different opinions about this? :)

1 1

Summary of Python tracker Issues
by Python tracker 16 Apr '10

16 Apr '10

ACTIVITY SUMMARY (2010-04-09 - 2010-04-16) 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. 2658 open (+38) / 17582 closed (+25) / 20240 total (+63) Open issues with patches: 1090 Average duration of open issues: 728 days. Median duration of open issues: 492 days. Open Issues Breakdown open 2616 (+38) languishing 9 ( +0) pending 32 ( +0) Issues Created Or Reopened (68) _______________________________ Add "key" argument to "bisect" module functions 2010-04-14 http://bugs.python.org/issue4356 reopened rhettinger patch AttributeError: MSVCCompiler instance has no attribute '_MSVCC 2010-04-13 http://bugs.python.org/issue7509 reopened tarek configure: ignore AC_PROG_CC hardcoded CFLAGS 2010-04-11 http://bugs.python.org/issue8211 reopened lemburg patch test_ctypes fails in test_ulonglong on sparc buildbots 2010-04-12 http://bugs.python.org/issue8314 reopened pitrou patch, buildbot Add a --show-installation-paths in the install command 2010-04-09 http://bugs.python.org/issue8357 reopened tarek absolute_import future directive ignored by 2to3 2010-04-09 CLOSED http://bugs.python.org/issue8358 created jaraco % formating - TypeError: not all arguments converted during st 2010-04-10 CLOSED http://bugs.python.org/issue8359 created sneetsher doc: unittest.skipTest method added in 2.7 2010-04-10 CLOSED http://bugs.python.org/issue8360 created techtonik patch Remove assert in functools.total_ordering 2010-04-10 CLOSED http://bugs.python.org/issue8361 created merwok patch Add Misc/maintainers.rst to 2.x branch 2010-04-10 http://bugs.python.org/issue8362 created merwok patch, needs review Lots of duplicate code between test_classify_oldstyle and test 2010-04-10 CLOSED http://bugs.python.org/issue8363 created exarkun patch, needs review Update site.setquit docstring 2010-04-10 CLOSED http://bugs.python.org/issue8364 created merwok patch 'readline' module fails to build on OS X - some recent change 2010-04-11 CLOSED http://bugs.python.org/issue8365 created l0nwlf OS X universal builds fail on 2.7b1 and py3k with "Don't know 2010-04-11 http://bugs.python.org/issue8366 created ned.deily test_winsound: failure on systems without soundcard 2010-04-11 CLOSED http://bugs.python.org/issue8367 created skrah patch Memory leak on multi-threaded PyObject_CallObject 2010-04-11 CLOSED http://bugs.python.org/issue8368 created Krauzi Add a lint command to distutils 2010-04-11 http://bugs.python.org/issue8369 created merwok change module "builtins" to "__builtin__" in __import__ docume 2010-04-11 CLOSED http://bugs.python.org/issue8370 created cjerdonek patch Add a command to download distributions 2010-04-11 http://bugs.python.org/issue8371 created merwok socket: Buffer overrun while reading unterminated AF_UNIX addr 2010-04-11 http://bugs.python.org/issue8372 created baikie patch socket: AF_UNIX socket paths not handled according to PEP 383 2010-04-11 http://bugs.python.org/issue8373 created baikie patch Some locales are unsupported 2010-04-11 CLOSED http://bugs.python.org/issue8374 created ubuntujenkins test_distutils fails when run with -j 2010-04-11 CLOSED http://bugs.python.org/issue8375 created pitrou Tutorial offers dangerous advice about iterators: “__iter__( 2010-04-12 http://bugs.python.org/issue8376 created andersk Errata on page:http://docs.python.org/library/stdtypes.html 2010-04-12 CLOSED http://bugs.python.org/issue8377 created jatin085 PYTHONSTARTUP is not run by default when Idle is started 2010-04-12 http://bugs.python.org/issue8378 created jvanpraag if __debug__: has nonobvious behaviour when evaluating .pyo wi 2010-04-12 CLOSED http://bugs.python.org/issue8379 created afriesen Port of the gdb7 debugging hooks to the "py3k" branch 2010-04-12 http://bugs.python.org/issue8380 created dmalcolm patch IDLE 2.6 freezes on OS X 10.6 2010-04-12 http://bugs.python.org/issue8381 created aaron.the.cow StringIO.write() takes any argument and converts it to a strin 2010-04-12 CLOSED http://bugs.python.org/issue8382 created tarek pickle is unable to encode unicode surrogates 2010-04-13 CLOSED http://bugs.python.org/issue8383 created haypo patch Distutils C extension build with MinGW on Windows fails 2010-04-13 http://bugs.python.org/issue8384 created cmcqueen1975 easy _winreg remaining in test_winsound 2010-04-13 CLOSED http://bugs.python.org/issue8385 created tim.golden patch test_pickle failing 2010-04-13 CLOSED http://bugs.python.org/issue8386 created tim.golden use universal newline mode in csv module examples 2010-04-13 http://bugs.python.org/issue8387 created sfinnie None shouldn't be passed to traceback.format_exception 2010-04-13 http://bugs.python.org/issue8388 created benjamin.peterson Incomprehensible import error 2010-04-13 CLOSED http://bugs.python.org/issue8389 created torsten tarfile: use surrogates for undecode fields 2010-04-13 http://bugs.python.org/issue8390 created haypo patch os.execvpe() doesn't support surrogates in env 2010-04-14 http://bugs.python.org/issue8391 created haypo patch unit tests rather light on testing __import__(..., level) 2010-04-14 http://bugs.python.org/issue8392 created skip.montanaro patch, needs review subprocess: support undecodable current working directory on P 2010-04-14 http://bugs.python.org/issue8393 created haypo patch ctypes.dlopen() doesn't support surrogates 2010-04-14 http://bugs.python.org/issue8394 created haypo patch shutil.copytree() add a copy_func parameter. 2010-04-14 http://bugs.python.org/issue8395 created ysj.ray tarfile.open does fails with UnicodeDecodeError if parent dir 2010-04-14 CLOSED http://bugs.python.org/issue8396 created parthm BZ2File doesn't protect against mixed iterator and read usage 2010-04-14 http://bugs.python.org/issue8397 created Alex.Stapleton Modules with a dot in the filename don't load 2010-04-14 CLOSED http://bugs.python.org/issue8398 created giunghi Document os.open 2010-04-14 CLOSED http://bugs.python.org/issue8399 reopened techtonik patch zipimporter find_module fullname mis-documented 2010-04-14 http://bugs.python.org/issue8400 created kmtracey Strange behavior of bytearray slice assignment 2010-04-14 http://bugs.python.org/issue8401 created abacabadabacaba patch glob returns empty list with "[" character in the folder name 2010-04-15 http://bugs.python.org/issue8402 reopened george.hu dis.dis gives different results if Ctrl-C is pressed 2010-04-15 http://bugs.python.org/issue8403 created ivank Set operations don't work for dictionary views 2010-04-15 http://bugs.python.org/issue8404 created akuchling patch Improve test_os._kill (failing on slow machines) 2010-04-15 http://bugs.python.org/issue8405 created brian.curtin patch Make some setup.py paths exclude-able 2010-04-15 http://bugs.python.org/issue8406 created skip.montanaro patch expose signalfd(2) and sigprocmask(2) in the signal module 2010-04-15 http://bugs.python.org/issue8407 created exarkun need console/pager module 2010-04-15 CLOSED http://bugs.python.org/issue8408 created techtonik gettext should honor $LOCPATH environment variable 2010-04-15 http://bugs.python.org/issue8409 created barry easy Fix emulated lock to be 'fair' 2010-04-15 http://bugs.python.org/issue8410 created krisvale patch, patch, needs review Improve condition variable emulation on NT 2010-04-15 http://bugs.python.org/issue8411 created krisvale patch, patch, needs review os.system() doesn't support surrogates nor bytes 2010-04-16 CLOSED http://bugs.python.org/issue8412 created haypo patch String interpolation doesn't work with sys.version_info 2010-04-16 http://bugs.python.org/issue8413 created Arfrever Add test cases for assert 2010-04-16 http://bugs.python.org/issue8414 created gnofi patch namedtuple vs tuple 2010-04-16 CLOSED http://bugs.python.org/issue8415 created hkrishnan python 2.6.5 documentation can't search 2010-04-16 http://bugs.python.org/issue8416 created sgala bytes and bytearray constructors raise TypeError for very larg 2010-04-16 http://bugs.python.org/issue8417 created abacabadabacaba Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program 2010-04-16 http://bugs.python.org/issue8418 created alfps dict constructor allows invalid identifiers in **kwargs 2010-04-16 http://bugs.python.org/issue8419 created mark.dickinson set_lookkey is unsafe 2010-04-16 http://bugs.python.org/issue8420 created abacabadabacaba Issues Now Closed (54) ______________________ _fmode = O_TEXT is obsolete 797 days http://bugs.python.org/issue2028 techtonik add ftp-tls support to ftplib - RFC 4217 793 days http://bugs.python.org/issue2054 orsenthil patch __import__ with fromlist= 793 days http://bugs.python.org/issue2090 gsakkis RFC2732 support for urlparse (IPv6 addresses) 689 days http://bugs.python.org/issue2987 orsenthil patch, easy failures in test_uuid 603 days http://bugs.python.org/issue3581 skrah patch Build failure on OpenBSD 4.4-current regarding lstat() 486 days http://bugs.python.org/issue4639 skrah patch Document __instancecheck__ and __subclasscheck__ 425 days http://bugs.python.org/issue5250 georg.brandl patch email message.get_params() and related methods sometimes fail. 423 days http://bugs.python.org/issue5277 r.david.murray patch, easy A selection of spelling errors and typos throughout source 69 days http://bugs.python.org/issue5341 merwok patch Strange behavior when performing int on a Decimal made from -s 411 days http://bugs.python.org/issue5377 mark.dickinson patch urllib.request.open(someURL).read() returns a bytes object so 407 days http://bugs.python.org/issue5419 orsenthil easy 2to3 -j 4 generates malformed diffs 283 days http://bugs.python.org/issue6409 benjamin.peterson patch test_urllib: unsetting missing 'env' variable 20 days http://bugs.python.org/issue7026 orsenthil Add environment variable $PYTHONWARNINGS 8 days http://bugs.python.org/issue7301 pjenvey patch, needs review Patch - skip winsound tests if no default sound is configured 152 days http://bugs.python.org/issue7306 brian.curtin patch, needs review Add a timeout functionality to common locking operations 152 days http://bugs.python.org/issue7316 torsten patch, needs review difflib should separate filename from timestamp with tab 107 days http://bugs.python.org/issue7585 r.david.murray patch test_cmd_line fails with non-ascii path 107 days http://bugs.python.org/issue7605 haypo patch test_xmlrpc fails with non-ascii path 107 days http://bugs.python.org/issue7606 haypo patch Test issue 98 days http://bugs.python.org/issue7621 ezio.melotti test_uuid is invalid 95 days http://bugs.python.org/issue7650 skrah patch Remove precision restriction for integer formatting. 65 days http://bugs.python.org/issue7873 mark.dickinson easy Documentation of math.pow, math.hypot, and complex.__abs__ 6 days http://bugs.python.org/issue7947 mark.dickinson patch strftime bug when timedelta is negative 45 days http://bugs.python.org/issue8026 amaury.forgeotdarc urlunparse(urlparse('x://')) now returns 'x:' instead of 'x:// 7 days http://bugs.python.org/issue8339 orsenthil easy test_tag_configure fails on FreeBSD 7 days http://bugs.python.org/issue8344 loewis buildbot Old Version Name in Interactive Mode 2 days http://bugs.python.org/issue8346 georg.brandl absolute_import future directive ignored by 2to3 0 days http://bugs.python.org/issue8358 benjamin.peterson % formating - TypeError: not all arguments converted during st 3 days http://bugs.python.org/issue8359 dpm doc: unittest.skipTest method added in 2.7 0 days http://bugs.python.org/issue8360 georg.brandl patch Remove assert in functools.total_ordering 0 days http://bugs.python.org/issue8361 ezio.melotti patch Lots of duplicate code between test_classify_oldstyle and test 0 days http://bugs.python.org/issue8363 exarkun patch, needs review Update site.setquit docstring 2 days http://bugs.python.org/issue8364 merwok patch 'readline' module fails to build on OS X - some recent change 0 days http://bugs.python.org/issue8365 l0nwlf test_winsound: failure on systems without soundcard 1 days http://bugs.python.org/issue8367 skrah patch Memory leak on multi-threaded PyObject_CallObject 0 days http://bugs.python.org/issue8368 loewis change module "builtins" to "__builtin__" in __import__ docume 3 days http://bugs.python.org/issue8370 georg.brandl patch Some locales are unsupported 1 days http://bugs.python.org/issue8374 loewis test_distutils fails when run with -j 0 days http://bugs.python.org/issue8375 tarek Errata on page:http://docs.python.org/library/stdtypes.html 0 days http://bugs.python.org/issue8377 doerwalter if __debug__: has nonobvious behaviour when evaluating .pyo wi 2 days http://bugs.python.org/issue8379 brett.cannon StringIO.write() takes any argument and converts it to a strin 1 days http://bugs.python.org/issue8382 r.david.murray pickle is unable to encode unicode surrogates 0 days http://bugs.python.org/issue8383 haypo patch _winreg remaining in test_winsound 0 days http://bugs.python.org/issue8385 brian.curtin patch test_pickle failing 0 days http://bugs.python.org/issue8386 haypo Incomprehensible import error 1 days http://bugs.python.org/issue8389 brett.cannon tarfile.open does fails with UnicodeDecodeError if parent dir 0 days http://bugs.python.org/issue8396 haypo Modules with a dot in the filename don't load 0 days http://bugs.python.org/issue8398 ezio.melotti Document os.open 0 days http://bugs.python.org/issue8399 georg.brandl patch need console/pager module 1 days http://bugs.python.org/issue8408 r.david.murray os.system() doesn't support surrogates nor bytes 0 days http://bugs.python.org/issue8412 haypo patch namedtuple vs tuple 0 days http://bugs.python.org/issue8415 rhettinger os.kill on windows 1763 days http://bugs.python.org/issue1220212 brian.curtin patch Thread shutdown exception in Thread.notify() 798 days http://bugs.python.org/issue1722344 brett.cannon patch Top Issues Most Discussed (10) ______________________________ 30 Improve GIL in 2.7 13 days open http://bugs.python.org/issue8299 23 diff.py produce unified format by default 7 days open http://bugs.python.org/issue8355 23 test_os causes delayed failure on x86 gentoo buildbot: Unknown 454 days open http://bugs.python.org/issue4970 19 Some locales are unsupported 1 days closed http://bugs.python.org/issue8374 17 RFC2732 support for urlparse (IPv6 addresses) 689 days closed http://bugs.python.org/issue2987 15 IGNORE_EXCEPTION_DETAIL should ignore the module name 124 days open http://bugs.python.org/issue7490 11 siginterrupt with flag=False is reset when signal received 7 days open http://bugs.python.org/issue8354 10 curses crash on FreeBSD 144 days open http://bugs.python.org/issue7384 9 Make some setup.py paths exclude-able 2 days open http://bugs.python.org/issue8406 9 Memory leak on multi-threaded PyObject_CallObject 0 days closed http://bugs.python.org/issue8368

1 0

urlparse - to parse IPv6 URL in 2.7 b2 ?
by Senthil Kumaran 16 Apr '10

16 Apr '10

http://bugs.python.org/issue2987 This deals with a feature request of parsing an IPv6 URL according to standards. The patch is pretty complete and we have good test coverage too. Is it okay to include this in Python 2.7 b2 release? It would be a worthy addition. -- Senthil

3 4

Google Groups mirror (Was: Bootstrap script for package management tool in Python 2.7)
by anatoly techtonik 16 Apr '10

16 Apr '10

On Mon, Mar 29, 2010 at 4:50 PM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > Anatoly, I am now answering only in Distutils-SIG. > > On Mon, Mar 29, 2010 at 3:45 PM, anatoly techtonik <techtonik(a)gmail.com> wrote: > [..] Seems like I start to hate mailing lists even more with all this message duplication and thread following nightmare. Why can't people here create a Google Groups mirror? -- anatoly t.

4 5

Request for commit access
by Brian Curtin 16 Apr '10

16 Apr '10

Hi all, Having been active in bug triage and patch writing/reviewing since late 2009, it was suggested in the python-dev IRC channel that I request commit access to the repository. I'm primarily a Windows user and have worked with many of the other active contributors to diagnose issues and test patches when they don't have direct access to Windows. Brian Curtin p.s. My contributor form in on file as of 2010-01-31.

11 11

Status of 2.7b1?
by Nick Coghlan 15 Apr '10

15 Apr '10

The trunk's been frozen for a few days now, which is starting to cut into the window for new fixes between b1 and b2 (down to just under 3 weeks, and that's only if b1 was ready for release today). Is work in train to address or document the remaining buildbot failures (e.g. test_os on Windows [1]). At what point do we decide to document something as a known defect in the beta and release it anyway? (My question is mostly aimed at Benjamin for obvious reasons, but it would be good to hear from anyone that is actually looking into the Windows buildbot failure) Cheers, Nick. [1] http://www.python.org/dev/buildbot/trunk/builders/x86%20XP-4%20trunk/builds… -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

6 7