<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#330033">
    On 4/27/2012 12:34 AM, Eric Snow wrote:
    <blockquote
cite="mid:CALFfu7DbaC0Dhvzzif+kBT42J13JFfgb8tdyR58yh2=h_t-kZQ@mail.gmail.com"
      type="cite">
      <pre wrap="">On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw <a class="moz-txt-link-rfc2396E" href="mailto:barry@python.org">&lt;barry@python.org&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
rationale section would be useful, at least.
</pre>
      </blockquote>
      <pre wrap="">
  <a class="moz-txt-link-freetext" href="http://mail.python.org/pipermail/python-ideas/2012-April/014954.html">http://mail.python.org/pipermail/python-ideas/2012-April/014954.html</a>
</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    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:<br>
    <br>
    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.<br>
    <br>
    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?)<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    So my thoughts are:<br>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    In this situation, sys.implementation, as proposed, should be
    implementation-specific.<br>
    <br>
  </body>
</html>