On Jun 2, 2012 12:30 AM, "Mark Shannon" <mark@hotpy.org> wrote:

Nick Coghlan wrote:

On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon <mark@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

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com