Mailman 3 February 2013 - Python-Dev

Postponing acceptance of PEP 426
by Nick Coghlan Feb. 21, 2013

Feb. 21, 2013

The feedback I have received (both on-list and in response to some off-list queries to specific people) tells me that PEP 426 isn't quite ready for acceptance yet. Things I'll be working on or facilitating over the next few weeks: - documenting an overall transition plan to put the new metadata format in context - clear acceptance criteria in PEP 426, primarily a list of specific projects and individuals that I have requested endorsement from before I am willing to accept the PEP - adding entry-points to PEP 426 - some more adjustments to PEP 426 for improved pkg_resources compatibility - some adjustments to PEP 426 for easier translation to JSON-compatible structured data - PEP for a standardised approach to metadata caching in installation databases - draft PEP for adding distlib to Python 3.4 - draft PEP for automated conversion of PEP 426 metadata files to JSON-compatible structured data This postpone does mean the initial wheel rollout in various projects will be based on metadata 1.2 + the Provides-Extra field (and associated environment marker change), rather than being cleanly based on metadata 2.0. I can live with that - that part of the PEP is *not* open to change, but there are other legitimate concerns that need to be addressed before I declare the PEP accepted. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Python-Dev] [Python-checkins] cpython (3.3): Rebuild importlib.h after the changes introduced in 0f65bf6063ca.
by Eric Snow Feb. 20, 2013

Feb. 20, 2013

On Wed, Feb 20, 2013 at 1:16 PM, ezio.melotti <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/9d00c79b27e1 > changeset: 82280:9d00c79b27e1 > branch: 3.3 > parent: 82278:96b4acb253f8 > user: Ezio Melotti <ezio.melotti(a)gmail.com> > date: Wed Feb 20 21:42:46 2013 +0200 > summary: > Rebuild importlib.h after the changes introduced in 0f65bf6063ca. Thanks, Ezio. -eric

1 0

The last Python 2.6 security release
by Barry Warsaw Feb. 20, 2013

Feb. 20, 2013

I just updated PEP 361 (Python 2.6 release schedule). Python 2.6 is in security maintenance, source only release mode. Official support for Python 2.6 expires on October 1 2013, and I would like to do one last release[1], i.e. 2.6.9 as close to that date as possible. I know of issue 16248, but if there are any other security issues that must be applied to 2.6, please let me know. Cheers, -Barry [1] Guido's time machine works in both directions and prevents a 2.6.10 from ever happening.

1 0

Python 2.7 buffer and memoryview documentation (issue# 17145)
by Demian Brecht Feb. 20, 2013

Feb. 20, 2013

http://bugs.python.org/issue17145 I'm curious as to whether or not anyone has reviewed the documentation update I made here. Context: Having both memory views and buffers in 2.7 (as well as the C-level API for each) is confusing. The initial bug report was to implement consistent behavior for objects supporting the new C-level buffer API or to update the docs. As new features are not being added to 2.7 (as pointed out by Stefan Krah), I made an update to the docs that I think made the disparity between the two (and when one should favour the usage of either) a little clearer. But maybe I'm off my rocker ;) Also, are contributor agreements also required for documentation? Thanks, Demian Brecht http://demianbrecht.github.com

2 1

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec fordistribution metadata 2.0
by a.cavallo＠cavallinux.eu Feb. 19, 2013

Feb. 19, 2013

> I've never seen environment markers being used or supported > in the wild. > > I'm not against modernizing the format, but given that version 1.2 > has been out for around 8 years now, without much following, > I think we need to make the implementation bit a requirement > before accepting the PEP. Elephant in the room? Somethin's been around for so long and hasn't got any sort of mainstream support is *not* a good candidate for a requirement but maybe it's me being naive.

5 5

Rationale for different signatures of tuple.__new__ and namedtuple.__new__
by John Reid Feb. 18, 2013

Feb. 18, 2013

Hi, I can do tuple([1,2,3]) but not: from collections import namedtuple namedtuple('B', 'x y z')([1,2,3]) I get a TypeError: __new__() takes exactly 4 arguments (2 given) However I can do: namedtuple('B', 'x y z')._make([1,2,3]) So namedtuple's _make classmethod looks a lot like tuple's __new__(). What's the rationale for this? Wouldn't it be better to share the same signature for __new__? IPython's serialization code depends on a tuple's __new__() having the signature that tuple has and therefore does not work with namedtuples. See discussion here: http://article.gmane.org/gmane.comp.python.general/726849 Thanks, John.

3 2

Re: [Python-Dev] cpython (2.7): Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
by Antoine Pitrou Feb. 18, 2013

Feb. 18, 2013

On Mon, 18 Feb 2013 11:24:40 +0100 (CET) serhiy.storchaka <python-checkins(a)python.org> wrote: > > + def test_realpath_curdir(self): > + self.assertEqual(realpath('.'), os.getcwd()) > + self.assertEqual(realpath('./.'), os.getcwd()) > + self.assertEqual(realpath('/'.join(['.'] * 100)), os.getcwd()) > + > + def test_realpath_pardir(self): > + self.assertEqual(realpath('..'), dirname(os.getcwd())) > + self.assertEqual(realpath('../..'), dirname(dirname(os.getcwd()))) > + self.assertEqual(realpath('/'.join(['..'] * 100)), '/') What if there's a symlink along os.getcwd()? Regards Antoine.

2 2

Re: [Python-Dev] cpython: Issue #15022: Add pickle and comparison support to types.SimpleNamespace.
by Antoine Pitrou Feb. 17, 2013

Feb. 17, 2013

Hello, On Sun, 17 Feb 2013 00:42:26 +0100 (CET) eric.snow <python-checkins(a)python.org> wrote: > > + def test_pickle(self): > + ns = types.SimpleNamespace(breakfast="spam", lunch="spam") > + > + ns_pickled = pickle.dumps(ns) > + ns_roundtrip = pickle.loads(ns_pickled) > + > + self.assertEqual(ns, ns_roundtrip) > + I think you should test with all pickle protocols. Regards Antoine.

3 4

Cut/Copy/Paste items in IDLE right click context menu
by Andrew Svetlov Feb. 17, 2013

Feb. 17, 2013

Hi. There are issue for subject: http://bugs.python.org/issue1207589 It has patches, implemented well and committed. I've pushed it to versions 2.7, 3.2, 3.3 and 3.4. My thoughts are: the issue is not brand new subject but improvement for current IDLE functionality. Added code cannot break any existing program/library I hope, it's related to humans who use IDLE only. It is desirable feature and probably IDLE users will be ok with new items in context menu even they are still 2.7 users. There are another opinion: it is new feature, not a bug, and the patch should be applied to 3.4 only. If you look on discussion for issue (http://bugs.python.org/issue1207589) you can see we cannot make decision, votes are split. I want to raise the question on this mailing list (as Terry Reedy suggested) to ask for community opinion. Thanks, Andrew Svetlov

7 13

Submitting PEP 425 (compatibility tags)
by Daniel Holth Feb. 17, 2013

Feb. 17, 2013

This is the improved compatibility tags PEP 425, specifying how part of the Wheel PEP 427 filenames work. Last time we discussed whether replacing . with _ was ugly but I concluded it was harmless. Submitted for your consideration, PEP: 425 Title: Compatibility Tags for Built Distributions Version: $Revision$ Last-Modified: 07-Aug-2012 Author: Daniel Holth <dholth(a)fastmail.fm> BDFL-Delegate: Nick Coghlan <ncoghlan(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 27-Jul-2012 Python-Version: 3.4 Post-History: 8-Aug-2012, 18-Oct-2012, 15-Feb-2013 Abstract ======== This PEP specifies a tagging system to indicate with which versions of Python a built or binary distribution is compatible. A set of three tags indicate which Python implementation and language version, ABI, and platform a built distribution requires. The tags are terse because they will be included in filenames. PEP Editor's Note ================= While the naming scheme described in this PEP will not be supported directly in the standard library until Python 3.4 at the earliest, draft implementations may be made available in third party projects. Rationale ========= Today "python setup.py bdist" generates the same filename on PyPy and CPython, but an incompatible archive, making it inconvenient to share built distributions in the same folder or index. Instead, built distributions should have a file naming convention that includes enough information to decide whether or not a particular archive is compatible with a particular implementation. Previous efforts come from a time where CPython was the only important implementation and the ABI was the same as the Python language release. This specification improves upon the older schemes by including the Python implementation, language version, ABI, and platform as a set of tags. By comparing the tags it supports with the tags listed by the distribution, an installer can make an educated decision about whether to download a particular built distribution without having to read its full metadata. Overview ======== The tag format is {python tag}-{abi tag}-{platform tag} python tag ‘py27’, ‘cp33’ abi tag ‘cp32dmu’, ‘none’ platform tag ‘linux_x86_64’, ‘any’ For example, the tag py27-none-any indicates compatible with Python 2.7 (any Python 2.7 implementation) with no abi requirement, on any platform. Use === The `wheel` built package format includes these tags in its filenames, of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``. Other package formats may have their own conventions. Details ======= Python Tag ---------- The Python tag indicates the implementation and version required by a distribution. Major implementations have abbreviated codes, initially: * py: Generic Python (does not require implementation-specific features) * cp: CPython * ip: IronPython * pp: PyPy * jy: Jython Other Python implementations should use `sys.implementation.name`. The version is `py_version_nodot`. CPython gets away with no dot, but if one is needed the underscore `_` is used instead. PyPy should probably use its own versions here `pp18`, `pp19`. The version can be just the major version `2` or `3` `py2`, `py3` for many pure-Python distributions. Importantly, major-version-only tags like `py2` and `py3` are not shorthand for `py20` and `py30`. Instead, these tags mean the packager intentionally released a cross-version-compatible distribution. A single-source Python 2/3 compatible distribution can use the compound tag `py2.py3`. See `Compressed Tag Sets`, below. ABI Tag ------- The ABI tag indicates which Python ABI is required by any included extension modules. For implementation-specific ABIs, the implementation is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be the CPython 3.3 ABI with debugging. The CPython stable ABI is `abi3` as in the shared library suffix. Implementations with a very unstable ABI may use the first 6 bytes (as 8 base64-encoded characters) of the SHA-256 hash of ther source code revision and compiler flags, etc, but will probably not have a great need to distribute binary distributions. Each implementation's community may decide how to best use the ABI tag. Platform Tag ------------ The platform tag is simply `distutils.util.get_platform()` with all hyphens `-` and periods `.` replaced with underscore `_`. * win32 * linux_i386 * linux_x86_64 Use === The tags are used by installers to decide which built distribution (if any) to download from a list of potential built distributions. The installer maintains a list of (pyver, abi, arch) tuples that it will support. If the built distribution's tag is `in` the list, then it can be installed. For example, an installer running under CPython 3.3 on a linux_x86_64 system might support:: 1. cp33-cp33m-linux_x86_64 2. cp33-abi3-linux_x86_64 3. cp33-none-linux_x86_64 4. cp33-none-any 5. cp3-none-any 6. cp32-none-any 7. cp31-none-any 8. cp30-none-any 9. py33-none-any 10. py3-none-any 11. py32-none-any 12. py31-none-any 13. py30-none-any The list is in order from most-preferred (a distribution with a compiled extension module, built for the current version of Python) to least-preferred (a pure-Python distribution built with an older version of Python). A user could instruct their installer to fall back to building from an sdist more or less often by configuring this list of tags; for example, a user could include only the `*-none-any` tags to only download built packages that advertise themselves as being pure Python. Rarely there will be more than one supported built distribution for a particular version of a package. For example, a packager could release a package tagged `cp33-abi3-linux_x86_64` that contains an optional C extension and the same distribution tagged `py3-none-any` that does not. The index of the tag in the supported tags list breaks the tie, and the package with the C extension is installed in preference to the package without because that tag appears first in the list. Compressed Tag Sets =================== To allow for compact filenames of bdists that work with more than one compatibility tag triple, each tag in a filename can instead be a '.'-separated, sorted, set of tags. For example, pip, a pure-Python package that is written to run under Python 2 and 3 with the same source code, could distribute a bdist with the tag `py2.py3-none-any`. The full list of simple tags is:: for x in pytag.split('.'): for y in abitag.split('.'): for z in archtag.split('.'): yield '-'.join((x, y, z)) A bdist format that implements this scheme should include the expanded tags in bdist-specific metadata. This compression scheme can generate large numbers of unsupported tags and "impossible" tags that are supported by no Python implementation e.g. "cp33-cp31u-win64", so use it sparingly. FAQ === What tags are used by default? Tools should use the most-preferred architecture dependent tag e.g. `cp33-cp33m-win32` or the most-preferred pure python tag e.g. `py33-none-any` by default. If the packager overrides the default it indicates that they intended to provide cross-Python compatibility. Can I have a tag `py32+` to indicate a minimum Python minor release? No. Inspect the Trove classifiers to determine this level of cross-release compatibility. Similar to the announcements "beaglevote versions 3.2 and above no longer supports Python 1.52", you will have to manually keep track of the maximum (PEP-386) release that still supports your version of Python. Why isn't there a `.` in the Python version number? CPython has lasted 20+ years without a 3-digit major release. This should continue for some time. Other implementations may use _ as a delimeter, since both - and . delimit the surrounding filename. Who will maintain the registry of abbreviated implementations? New two-letter abbreviations can be requested on the python-dev mailing list. As a rule of thumb, abbreviations are reserved for the current 4 most prominent implementations. Does the compatibility tag go into METADATA or PKG-INFO? No. The compatibility tag is part of the built distribution's metadata. METADATA / PKG-INFO should be valid for an entire distribution, not a single build of that distribution. Why didn't you mention my favorite Python implementation? The abbreviated tags facilitate sharing compiled Python code in a public index. Your Python implementation can use this specification too, but with longer tags. Recall that all "pure Python" built distributions just use 'py'. References ========== .. [1] Egg Filename-Embedded Metadata ( http://peak.telecommunity.com/DevCenter/EggFormats#filename-embedded-metada… ) .. [2] Creating Built Distributions (http://docs.python.org/distutils/builtdist.html) .. [3] PEP 3147 -- PYC Repository Directories (http://www.python.org/dev/peps/pep-3147/) Acknowledgements ================ The author thanks Paul Moore, Nick Coghlan, Mark Abramowitz, and Mr. Michele Lacchia for their valuable advice and help with this effort. 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:

2 2