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" <m...@hotpy.org> wrote:
> Nick Coghlan wrote:
>
>> On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon <m...@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<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> ncoghlan%40gmail.com<http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com>
>
_______________________________________________
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/archive%40mail-archive.com
