[Python-Dev] sys.implementation

[Glenn Linderman]

On 4/27/2012 12:34 AM, Eric Snow wrote:
> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw<barry at python.org>  wrote:
>> It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
>> rationale section would be useful, at least.
>    http://mail.python.org/pipermail/python-ideas/2012-April/014954.html

The idea of having separate versions for CPython and stdlib has been 
raised recently, although I believe it has been mostly been deferred or 
discarded.  Should that be resurrected, sys.implementation may be a good 
repository for the additional version info defining the stdlib version.

However, this PEP raises the following question in my mind: is the sys 
module part of the stdlib? Before reaching a hasty conclusion, consider 
the following points:

1) with this proposal, the contents of sys.implementation will vary 
between implementations.  If stdlib is to be shared among 
implementations, then it seems sys.implementation should not be part of 
the stdlib, but rather part of the implementation. Is sys considered 
part of the implementation or part of the stdlib? I've always perceived 
it as part of the stdlib, because of the way it is documented.

2) importlib wants to be part of the stdlib, and thus available to other 
implementations, but it must be built-in or frozen. The goal with 
importlib is a common implementation in Python, that can be used by all 
implementations.  I am not clear on whether the accelerated C code is 
part of the stdlib, or part of an implementation optimization, nor how 
the structuring of such things is arranged to separate stdlib from 
implementation (if it is; if it isn't, should it be?)

3) can anything that must be built-in or frozen be part of the stdlib? I 
don't see why not, if it is common to all implementations, even if it 
depends on data it obtains from the implementation via some mechanism 
such as the proposed sys.implementation. However, if it is not common, I 
don't know how it can be standard/stdlib... which raises issues in my 
understanding of the various modules available as Python with C 
accelerators, and I know there are pure C modules that are part of the 
stdlib. So I think this idea of making the stdlib more sharable between 
implementations is still a work-in-progress, even a design-in-progress, 
but maybe part of the solution is to separate, or at least delineate, 
things that can be common, from things that cannot be common to all 
implementations.

My conclusion is that sys.implementation clearly should not be part of 
the stdlib, but rather be part of the language implementation.  Whether 
it then fits with the rest of what is in sys, or not, I am not qualified 
to say.  If not, perhaps a new module name is warranted... perhaps 
"implementation" at the top level of the namespace.

So my thoughts are:

Things that are part of the stdlib should be available in Python source 
to be shared across implementations.  Things that are not available in 
Python source cannot be shared across implementations, and therefore 
should not be part of the stdlib, but rather part of an 
implementation-specific library, or part of the language specification.

Or maybe stdlib should be an umbrella term, with the following subsets: 
common (Python implementation available, and not dependent on 
implementation-specific details except in very standardized ways), 
implementation-specific (provided by each implementation, either in 
implementation-specific Python, or some other implementation language), 
accelerators (a faster version of a common module, provided by an 
implementation when necessary for performance).

In this situation, sys.implementation, as proposed, should be 
implementation-specific.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120427/d3b40c2b/attachment.html>