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

Mark Shannon mark at hotpy.org
Fri Jun 1 16:22:26 CEST 2012


Nick Coghlan wrote:
> 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

I thought this list was for CPython, not other implementations ;)

> 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.

I'm not arguing with the PEP, just discussing how to implement it.

> 
> 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.

Could you justify that last sentence. What is special about C that means 
that information does not have to be duplicated, yet it must be in Python?
I've already provided two implementations. The second derives all the 
information it needs from other sources, thus conforming to DRY.
If the use of imp bothers you, then would this be OK:

I just picked imp.get_tag() because it has the relevant info. Would:

sys.implementation.cache_tag = (sys.implementation.name + '-' + 
str(sys.version_info[0]) + str(str(sys.version_info[1]))

be acceptable?

> 
> 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.

I don't see how that is relevant. sys.implementation can never be part 
of the shared stdlib. That does not mean it has to be implemented in C.

Cheers,
Mark



More information about the Python-Dev mailing list