[Python-Dev] sys.implementation

Nick Coghlan ncoghlan at gmail.com
Sat Apr 28 09:58:37 CEST 2012

On Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> Here's a ponderable: In the long term, should the documentation be unified
> for multiple implementations?  Or should it be split into 4 pieces, so that
> alternate implementations could swap in their own sections for
> implementation dependent items?

Probably not, because the boundary between language, standard library
and implementation *is* blurry. The blurriness in the descriptions
reflects the blurriness in reality.

Anything that doesn't have dedicated syntax is, in a formal sense,
part of the standard library rather than the core language definition.
That includes the GC API, the weakref API, the sys module, the
operator module, the builtins module, the types module, etc. The
language specification itself just states that there *is* a builtin
namespace and you *can* do imports. It is then up to the standard
library specification to describe the *contents* of the builtin
namespace, as well as state what other modules and packages can be
imported by default.

However, the various parts of the standard library differ can wildly
in how *closely coupled* they are to a particular implementation.

Some, such as builtins, gc, operator, weakref, types and sys are
*very* tightly coupled with a specific implementation and always will
be. If someone is writing a new implementation of Python, they're
almost certainly going to have to write new version of these modules
from scratch that interoperate correctly with their code generator and
evaluation loop.

Historically, the import machinery was similarly coupled to a specific
implementation. The goal of bootstrapping importlib as the main import
implementation is to change that so that most of the import machinery
is decoupled from the implementation, with the bare minimum remaining
as implementation specific code (specifically, the code needed to
carry out the bootstrapping process, such as supporting frozen and
builtin modules).

Other modules may differ in performance characteristics between
implementations, particular for older C modules in CPython which don't
have a pure Python counterpart.

So, yes, I agree the four categories you list are helpful in
*thinking* about the questions involved, but, no, I don't think it's a
good principle for organising the documentation (precisely because the
categories are related to implementation details that shouldn't matter
all that much to end users).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list