<p>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. </p>
<p>--<br>
Sent from my phone, thus the relative brevity :) </p>
<div class="gmail_quote">On Jun 2, 2012 12:30 AM, "Mark Shannon" <<a href="mailto:mark@hotpy.org">mark@hotpy.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nick Coghlan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jun 1, 2012 at 11:17 PM, Mark Shannon <<a href="mailto:mark@hotpy.org" target="_blank">mark@hotpy.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
import imp<br>
tag = imp.get_tag()<br>
<br>
sys.implementation = SysImplementation()<br>
<a href="http://sys.implementation.name" target="_blank">sys.implementation.name</a> = tag[:tag.index('-')]<br>
sys.implementation.version = sys.version_info<br>
sys.implementation.hexversion = sys.hexversion<br>
</blockquote>
<br>
This is wrong. sys.version_info is the language version, while<br>
sys.implementation.version is the implementation version. They happen<br>
to be the same for CPython because it's the reference interpreter, but<br>
</blockquote>
<br>
I thought this list was for CPython, not other implementations ;)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
splitting the definition like this allows (for example) a 0.1 release<br>
of a new implementation to target Python 3.3 and clearly indicate the<br>
difference between the two version numbers.<br>
<br>
As the PEP's rationale section says: "The status quo for<br>
implementation-specific information gives us that information in a<br>
more fragile, harder to maintain way. It is spread out over different<br>
modules or inferred from other information, as we see with<br>
platform.python_<u></u>implementation().<br>
<br>
This PEP is the main alternative to that approach. It consolidates the<br>
implementation-specific information into a single namespace and makes<br>
explicit that which was implicit."<br>
<br>
The idea of the PEP is provide a standard channel from the<br>
implementation specific parts of the interpreter (i.e. written in the<br>
implementation language) through to the implementation independent<br>
code in the standard library (i.e. written in Python). It's intended<br>
to *replace* the legacy APIs in the long run, not rely on them.<br>
</blockquote>
<br>
I'm not arguing with the PEP, just discussing how to implement it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While we're unlikely to bother actually deprecating legacy APIs like<br>
imp.get_tag() (as it isn't worth the hassle), PEP 421 means we can at<br>
least avoid *adding* to them. To achieve the aims of the PEP without<br>
double-keying data it *has* to be written in C.<br>
</blockquote>
<br>
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?<br>
I've already provided two implementations. The second derives all the information it needs from other sources, thus conforming to DRY.<br>
If the use of imp bothers you, then would this be OK:<br>
<br>
I just picked imp.get_tag() because it has the relevant info. Would:<br>
<br>
sys.implementation.cache_tag = (<a href="http://sys.implementation.name" target="_blank">sys.implementation.name</a> + '-' + str(sys.version_info[0]) + str(str(sys.version_info[1]))<br>
<br>
be acceptable?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The long term goal here is that all the code in the standard library<br>
should be implementation independent - PyPy, Jython, IronPython, et al<br>
should be able to grab it and just run it. That means the<br>
implementation specific stuff needs to migrate into the C code and get<br>
exposed through standard APIs. PEP 421 is one step along that road.<br>
</blockquote>
<br>
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.<br>
<br>
Cheers,<br>
Mark<br>
<br>
______________________________<u></u>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com" target="_blank">http://mail.python.org/<u></u>mailman/options/python-dev/<u></u>ncoghlan%40gmail.com</a><br>
</blockquote></div>