[Python-Dev] sys.implementation (original) (raw)

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).

Cheers, Nick.

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

More information about the Python-Dev mailing list