[Python-Dev] a new type for sys.implementation (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Fri Jun 1 15:49:49 CEST 2012


On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon <mark at hotpy.org> wrote:

import imp tag = imp.gettag()

sys.implementation = SysImplementation() sys.implementation.name = tag[:tag.index('-')] sys.implementation.version = sys.versioninfo sys.implementation.hexversion = sys.hexversion

This is wrong. sys.version_info is the language version, while sys.implementation.version is the implementation version. They happen to be the same for CPython because it's the reference interpreter, but splitting the definition like this allows (for example) a 0.1 release of a new implementation to target Python 3.3 and clearly indicate the difference between the two version numbers.

As the PEP's rationale section says: "The status quo for implementation-specific information gives us that information in a more fragile, harder to maintain way. It is spread out over different modules or inferred from other information, as we see with platform.python_implementation().

This PEP is the main alternative to that approach. It consolidates the implementation-specific information into a single namespace and makes explicit that which was implicit."

The idea of the PEP is provide a standard channel from the implementation specific parts of the interpreter (i.e. written in the implementation language) through to the implementation independent code in the standard library (i.e. written in Python). It's intended to replace the legacy APIs in the long run, not rely on them.

While we're unlikely to bother actually deprecating legacy APIs like imp.get_tag() (as it isn't worth the hassle), PEP 421 means we can at least avoid adding to them. To achieve the aims of the PEP without double-keying data it has to be written in C.

The long term goal here is that all the code in the standard library should be implementation independent - PyPy, Jython, IronPython, et al should be able to grab it and just run it. That means the implementation specific stuff needs to migrate into the C code and get exposed through standard APIs. PEP 421 is one step along that road.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-Dev mailing list