[Python-Dev] a new type for sys.implementation

[Nick Coghlan]

On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon <mark at hotpy.org> wrote:
> import imp
> tag = imp.get_tag()
>
> sys.implementation = SysImplementation()
> sys.implementation.name = tag[:tag.index('-')]
> sys.implementation.version = sys.version_info
> 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