You have the burden of proof the wrong way around. sys is a builtin module. C is the default language, absent a compelling reason to use Python instead. The code is simple enough that there is no such reason, thus the implementation will be in C.
-- Sent from my phone, thus the relative brevity :) 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-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** ncoghlan%40gmail.comhttp://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com