On 4/27/2012 12:34 AM, Eric Snow wrote: 
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw <barry@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.