2012-04-27 17:32:38 -04:00
|
|
|
|
PEP: 421
|
|
|
|
|
Title: Adding sys.implementation
|
|
|
|
|
Version: $Revision$
|
|
|
|
|
Last-Modified: $Date$
|
|
|
|
|
Author: Eric Snow <ericsnowcurrently@gmail.com>
|
|
|
|
|
Status: Draft
|
|
|
|
|
Type: Standards Track
|
|
|
|
|
Content-Type: text/x-rst
|
|
|
|
|
Created: 26-April-2012
|
|
|
|
|
Post-History: 26-April-2012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
========
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
This PEP introduces a new attribute for the ``sys`` module:
|
|
|
|
|
``sys.implementation``. The attribute holds consolidated information
|
|
|
|
|
about the implementation of the running interpreter. Thus
|
|
|
|
|
``sys.implementation`` is the source to which the standard library may
|
|
|
|
|
look for implementation-specific information.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
The proposal in this PEP is in line with a broader emphasis on making
|
|
|
|
|
Python friendlier to alternate implementations. It describes the new
|
|
|
|
|
variable and the constraints on what that variable contains. The PEP
|
|
|
|
|
also explains some immediate use cases for ``sys.implementation``.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Motivation
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
For a number of years now, the distinction between Python-the-language
|
|
|
|
|
and CPython (the reference implementation) has been growing. Most of
|
|
|
|
|
this change is due to the emergence of Jython, IronPython, and PyPy as
|
|
|
|
|
viable alternate implementations of Python.
|
|
|
|
|
|
|
|
|
|
Consider, however, the nearly two decades of CPython-centric Python
|
2012-05-01 02:51:22 -04:00
|
|
|
|
(i.e. most of its existence). That focus had understandably
|
|
|
|
|
contributed to quite a few CPython-specific artifacts both in the
|
|
|
|
|
standard library and exposed in the interpreter. Though the core
|
|
|
|
|
developers have made an effort in recent years to address this, quite
|
|
|
|
|
a few of the artifacts remain.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
Part of the solution is presented in this PEP: a single namespace in
|
2012-04-27 17:32:38 -04:00
|
|
|
|
which to consolidate implementation specifics. This will help focus
|
2012-05-01 02:51:22 -04:00
|
|
|
|
efforts to differentiate the implementation specifics from the
|
|
|
|
|
language. Additionally, it will foster a multiple-implementation
|
|
|
|
|
mindset.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Proposal
|
|
|
|
|
========
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
We will add a new attribute to the ``sys`` module, called
|
|
|
|
|
``sys.implementation``, as an instance of a new type to contain
|
2012-05-01 02:51:22 -04:00
|
|
|
|
implementation-specific information.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
The attributes of this object will remain fixed during interpreter
|
2012-04-27 17:32:38 -04:00
|
|
|
|
execution and through the course of an implementation version. This
|
2012-05-01 02:51:22 -04:00
|
|
|
|
ensures behaviors don't change between versions which depend on
|
|
|
|
|
variables in ``sys.implementation``.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
The object will have each of the attributes described in the `Required
|
|
|
|
|
Variables`_ section below. Any other per-implementation values may be
|
|
|
|
|
stored in ``sys.implementation.metadata``. However, nothing in the
|
|
|
|
|
standard library will rely on ``sys.implementation.metadata``.
|
|
|
|
|
Examples of possible metadata values are described in the `Example
|
|
|
|
|
Metadata Values`_ section.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
This proposal takes a conservative approach in requiring only four
|
2012-05-01 02:51:22 -04:00
|
|
|
|
variables. As more become appropriate, they may be added with
|
|
|
|
|
discretion.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Required Variables
|
2012-05-06 05:17:25 -04:00
|
|
|
|
------------------
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
These are variables in ``sys.implementation`` on which the standard
|
2012-05-06 05:17:25 -04:00
|
|
|
|
library would rely, with the exception of ``metadata``, meaning
|
|
|
|
|
implementers must define them:
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
**name**
|
2012-05-06 05:17:25 -04:00
|
|
|
|
This is the common name of the implementation (case sensitive).
|
|
|
|
|
Examples include 'PyPy', 'Jython', 'IronPython', and 'CPython'.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
**version**
|
2012-05-06 05:17:25 -04:00
|
|
|
|
This is the version of the implementation, as opposed to the
|
|
|
|
|
version of the language it implements. This value conforms to the
|
|
|
|
|
format described in `Version Format`_.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
**cache_tag**
|
2012-05-06 05:17:25 -04:00
|
|
|
|
A string used for the PEP 3147 cache tag [#cachetag]_. It would
|
|
|
|
|
normally be a composite of the name and version (e.g. 'cpython-33'
|
|
|
|
|
for CPython 3.3). However, an implementation may explicitly use a
|
|
|
|
|
different cache tag. If ``cache_tag`` is set to None, it indicates
|
|
|
|
|
that module caching should be disabled.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
**metadata**
|
|
|
|
|
Any other values that an implementation wishes to specify,
|
|
|
|
|
particularly informational ones. Neither the standard library nor
|
|
|
|
|
the language specification will rely on implementation metadata.
|
|
|
|
|
Also see the list of `Example Metadata Values`_.
|
|
|
|
|
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Adding New Required Attributes
|
|
|
|
|
------------------------------
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
XXX PEP? something lighter?
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Version Format
|
|
|
|
|
--------------
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
A main point of ``sys.implementation`` is to contain information that
|
|
|
|
|
will be used internally in the standard library. In order to
|
|
|
|
|
facilitate the usefulness of a version variable, its value should be
|
|
|
|
|
in a consistent format across implementations.
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
As such, the format of ``sys.implementation.version`` must follow that
|
|
|
|
|
of ``sys.version_info``, which is effectively a named tuple. It is a
|
|
|
|
|
familiar format and generally consistent with normal version format
|
|
|
|
|
conventions.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
XXX The following is not exactly true:
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Keep in mind, however, that ``sys.implementation.version`` is the
|
2012-05-01 02:51:22 -04:00
|
|
|
|
version of the Python *implementation*, while ``sys.version_info``
|
|
|
|
|
(and friends) is the version of the Python language.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Example Metadata Values
|
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
|
|
These are the sorts of values an implementation may put into
|
|
|
|
|
``sys.implementation.metadata``. However, these names and
|
|
|
|
|
descriptions are only examples and are not being proposed here. If
|
|
|
|
|
they later have meaningful uses cases, they can be added by following
|
|
|
|
|
the process described in `Adding New Required Attributes`_.
|
|
|
|
|
|
|
|
|
|
**vcs_url**
|
|
|
|
|
The URL pointing to the main VCS repository for the implementation
|
|
|
|
|
project.
|
|
|
|
|
|
|
|
|
|
**vcs_revision_id**
|
|
|
|
|
A value that identifies the VCS revision of the implementation that
|
|
|
|
|
is currently running.
|
|
|
|
|
|
|
|
|
|
**build_toolchain**
|
|
|
|
|
Identifies the tools used to build the interpreter.
|
|
|
|
|
|
|
|
|
|
**build_date**
|
|
|
|
|
The timestamp of when the interpreter was built.
|
|
|
|
|
|
|
|
|
|
**homepage**
|
|
|
|
|
The URL of the implementation's website.
|
|
|
|
|
|
|
|
|
|
**site_prefix**
|
|
|
|
|
The preferred site prefix for this implementation.
|
|
|
|
|
|
|
|
|
|
**runtime**
|
|
|
|
|
The run-time environment in which the interpreter is running, as
|
|
|
|
|
in "Common Language *Runtime*" (.NET CLR) or "Java *Runtime*
|
|
|
|
|
Executable".
|
|
|
|
|
|
|
|
|
|
**gc_type**
|
|
|
|
|
The type of garbage collection used, like "reference counting" or
|
|
|
|
|
"mark and sweep".
|
|
|
|
|
|
|
|
|
|
|
2012-04-27 17:32:38 -04:00
|
|
|
|
Rationale
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
The status quo for implementation-specific information gives us that
|
2012-05-06 05:17:25 -04:00
|
|
|
|
information in a more fragile, harder to maintain way. It is spread
|
2012-05-01 02:51:22 -04:00
|
|
|
|
out over different modules or inferred from other information, as we
|
2012-05-06 05:17:25 -04:00
|
|
|
|
see with `platform.python_implementation()`_.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
|
|
|
|
This PEP is the main alternative to that approach. It consolidates
|
|
|
|
|
the implementation-specific information into a single namespace and
|
|
|
|
|
makes explicit that which was implicit.
|
|
|
|
|
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Why a Custom Type?
|
|
|
|
|
------------------
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
A dedicated class, of which ``sys.implementation`` is an instance, would
|
|
|
|
|
facilitate the dotted access of a "named" tuple. At the same time, it
|
|
|
|
|
allows us to avoid the problems of the other approaches (see below),
|
|
|
|
|
like confusion about ordering and iteration.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
|
|
|
|
The alternatives to a dictionary are considered separately here:
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
**Dictionary**
|
|
|
|
|
|
|
|
|
|
A dictionary reflects a simple namespace with item access. It
|
|
|
|
|
maps names to values and that's all. It also reflects the more variable
|
|
|
|
|
nature of ``sys.implementation``.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
However, a simple dictionary does not set expectations very well about
|
|
|
|
|
the nature of ``sys.implementation``. The custom type approach, with
|
|
|
|
|
a fixed set of required attributes, does a better job of this.
|
|
|
|
|
|
|
|
|
|
**Named Tuple**
|
|
|
|
|
|
|
|
|
|
Another close alternative is a namedtuple or a structseq or some other
|
2012-05-01 02:51:22 -04:00
|
|
|
|
tuple type with dotted access (a la ``sys.version_info``). This type
|
|
|
|
|
is immutable and simple. It is a well established pattern for
|
2012-05-06 05:17:25 -04:00
|
|
|
|
implementation-specific variables in Python. Dotted access on a
|
2012-05-01 02:51:22 -04:00
|
|
|
|
namespace is also very convenient.
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Fallback lookup may favor dicts::
|
|
|
|
|
|
|
|
|
|
cache_tag = sys.implementation.get('cache_tag')
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
vs.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
cache_tag = getattr(sys.implementation.get, 'cache_tag', None)
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
However, this is mitigated by having ``sys.implementation.metadata``.
|
|
|
|
|
|
|
|
|
|
One problem with using a named tuple is that ``sys.implementation`` does
|
|
|
|
|
not have meaning as a sequence. Also, unlike other similar ``sys``
|
|
|
|
|
variables, it has a far greater potential to change over time.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
|
|
|
|
If a named tuple were used, we'd be very clear in the documentation
|
|
|
|
|
that the length and order of the value are not reliable. Iterability
|
|
|
|
|
would not be guaranteed.
|
|
|
|
|
|
|
|
|
|
**Module**
|
|
|
|
|
|
|
|
|
|
Using a module instead of a dict is another option. It has similar
|
|
|
|
|
characteristics to an instance, but with a slight hint of immutability
|
|
|
|
|
(at least by convention). Such a module could be a stand-alone sub-
|
|
|
|
|
module of ``sys`` or added on, like ``os.path``. Unlike a concrete
|
2012-05-06 05:17:25 -04:00
|
|
|
|
class, no new type would be necessary. This is a pretty close fit to
|
|
|
|
|
what we need.
|
|
|
|
|
|
|
|
|
|
The downside is that the module type is much less conducive to
|
|
|
|
|
extension, making it more difficult to address the weaknesses of using
|
|
|
|
|
an instance of a concrete class.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Why metadata?
|
|
|
|
|
-------------
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
``sys.implementation.metadata`` will hold any optional, strictly-
|
|
|
|
|
informational, or per-implementation data. This allows us to restrict
|
|
|
|
|
``sys.implementation`` to the required attributes. In that way, its
|
|
|
|
|
type can reflect the more stable namespace and
|
|
|
|
|
``sys.implementation.metadata`` (as a dict) can reflect the less
|
|
|
|
|
certain namespace.
|
|
|
|
|
|
|
|
|
|
``sys.implementation.metadata`` is the place an implementation can put
|
|
|
|
|
values that must be built-in, "without having to pollute the main sys
|
|
|
|
|
namespace" [#Nick]_.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Why a Part of ``sys``?
|
|
|
|
|
----------------------
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
The ``sys`` module should hold the new namespace because ``sys`` is
|
|
|
|
|
the depot for interpreter-centric variables and functions. Many
|
|
|
|
|
implementation-specific variables are already found in ``sys``.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Why Strict Constraints on Any of the Values?
|
|
|
|
|
--------------------------------------------
|
|
|
|
|
|
|
|
|
|
As already noted in `Version Format`_, values in
|
|
|
|
|
``sys.implementation`` are intended for use by the standard library.
|
|
|
|
|
Constraining those values, essentially specifying an API for them,
|
|
|
|
|
allows them to be used consistently, regardless of how they are
|
2012-05-06 05:17:25 -04:00
|
|
|
|
otherwise implemented.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Discussion
|
|
|
|
|
==========
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
The topic of ``sys.implementation`` came up on the python-ideas list
|
2012-05-06 05:17:25 -04:00
|
|
|
|
in 2009, where the reception was broadly positive [#original]_. I
|
|
|
|
|
revived the discussion recently while working on a pure-python
|
|
|
|
|
``imp.get_tag()`` [#revived]_. Discussion has been ongoing
|
|
|
|
|
[#feedback]_. The messages in `issue #14673`_ are also relevant.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use-cases
|
|
|
|
|
=========
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
platform.python_implementation()
|
|
|
|
|
--------------------------------
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
"explicit is better than implicit"
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
The ``platform`` module determines the python implementation by
|
|
|
|
|
looking for clues in a couple different ``sys`` variables [#guess]_.
|
|
|
|
|
However, this approach is fragile, requiring changes to the standard
|
|
|
|
|
library each time an implementation changes. Beyond that, support in
|
|
|
|
|
``platform`` is limited to those implementations that core developers
|
|
|
|
|
have blessed by special-casing them in the ``platform`` module.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
With ``sys.implementation`` the various implementations would
|
2012-05-01 02:51:22 -04:00
|
|
|
|
*explicitly* set the values in their own version of the ``sys``
|
|
|
|
|
module.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Another concern is that the ``platform`` module is part of the stdlib,
|
|
|
|
|
which ideally would minimize implementation details such as would be
|
|
|
|
|
moved to ``sys.implementation``.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
Any overlap between ``sys.implementation`` and the ``platform`` module
|
|
|
|
|
would simply defer to ``sys.implementation`` (with the same interface
|
|
|
|
|
in ``platform`` wrapping it).
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cache Tag Generation in Frozen Importlib
|
|
|
|
|
----------------------------------------
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
PEP 3147 defined the use of a module cache and cache tags for file
|
|
|
|
|
names. The importlib bootstrap code, frozen into the Python binary as
|
|
|
|
|
of 3.3, uses the cache tags during the import process. Part of the
|
2012-05-06 05:17:25 -04:00
|
|
|
|
project to bootstrap importlib has been to clean code out of
|
|
|
|
|
`Python/import.c`_ that did not need to be there any longer.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
The cache tag defined in ``Python/import.c`` was hard-coded to
|
|
|
|
|
``"cpython" MAJOR MINOR`` [#cachetag]_. For importlib the options are
|
|
|
|
|
either hard-coding it in the same way, or guessing the implementation
|
|
|
|
|
in the same way as does ``platform.python_implementation()``.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
As long as the hard-coded tag is limited to CPython-specific code, it
|
|
|
|
|
is livable. However, inasmuch as other Python implementations use the
|
|
|
|
|
importlib code to work with the module cache, a hard-coded tag would
|
|
|
|
|
become a problem.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
Directly using the ``platform`` module in this case is a non-starter.
|
|
|
|
|
Any module used in the importlib bootstrap must be built-in or frozen,
|
|
|
|
|
neither of which apply to the ``platform`` module. This is the point
|
|
|
|
|
that led to the recent interest in ``sys.implementation``.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
Regardless of the outcome for the implementation name used, another
|
|
|
|
|
problem relates to the version used in the cache tag. That version is
|
|
|
|
|
likely to be the implementation version rather than the language
|
|
|
|
|
version. However, the implementation version is not readily
|
2012-04-27 17:32:38 -04:00
|
|
|
|
identified anywhere in the standard library.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implementation-Specific Tests
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
Currently there are a number of implementation-specific tests in the
|
|
|
|
|
test suite under ``Lib/test``. The test support module
|
|
|
|
|
(`Lib/test/support.py`_) provides some functionality for dealing with
|
|
|
|
|
these tests. However, like the ``platform`` module, ``test.support``
|
|
|
|
|
must do some guessing that ``sys.implementation`` would render
|
|
|
|
|
unnecessary.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jython's ``os.name`` Hack
|
|
|
|
|
-------------------------
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
In Jython, ``os.name`` is set to 'java' to accommodate special
|
|
|
|
|
treatment of the java environment in the standard library [#os_name]_
|
|
|
|
|
[#javatest]_. Unfortunately it masks the os name that would otherwise
|
|
|
|
|
go there. ``sys.implementation`` would help obviate the need for this
|
|
|
|
|
special case.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
Feedback From Other Python Implementers
|
|
|
|
|
=======================================
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
IronPython
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
XXX
|
|
|
|
|
|
|
|
|
|
Jython
|
|
|
|
|
------
|
|
|
|
|
|
|
|
|
|
XXX
|
|
|
|
|
|
|
|
|
|
PyPy
|
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
XXX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Past Efforts
|
|
|
|
|
============
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
PEP 3139
|
|
|
|
|
--------
|
|
|
|
|
|
|
|
|
|
This PEP from 2008 recommended a clean-up of the ``sys`` module in
|
|
|
|
|
part by extracting implementation-specific variables and functions
|
|
|
|
|
into a separate module. PEP 421 is a much lighter version of that
|
|
|
|
|
idea. While PEP 3139 was rejected, its goals are reflected in PEP 421
|
|
|
|
|
to a large extent, though with a much lighter approach.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PEP 399
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
This informational PEP dictates policy regarding the standard library,
|
|
|
|
|
helping to make it friendlier to alternate implementations. PEP 421
|
|
|
|
|
is proposed in that same spirit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Alternatives
|
|
|
|
|
============
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
Since the single-namespace-under-sys approach is relatively
|
|
|
|
|
straightforward, no alternatives have been considered for this PEP.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Open Issues
|
|
|
|
|
===========
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
* What are the long-term objectives for ``sys.implementation``?
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
- possibly pull in implementation details from the main ``sys``
|
|
|
|
|
namespace and elsewhere (PEP 3137 lite).
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
* What is the process for introducing new required variables? PEP?
|
|
|
|
|
|
|
|
|
|
* Is the ``sys.version_info`` format the right one here?
|
|
|
|
|
|
|
|
|
|
* Should ``sys.implementation.hexversion`` be part of the PEP?
|
|
|
|
|
|
|
|
|
|
* Does ``sys.(version|version_info|hexversion)`` need to better
|
|
|
|
|
reflect the version of the language spec? Micro version, series,
|
|
|
|
|
and release seem like implementation-specific values.
|
|
|
|
|
|
2012-04-27 17:32:38 -04:00
|
|
|
|
* Alternatives to the approach dictated by this PEP?
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
* Do we really want to commit to using a dict for
|
|
|
|
|
``sys.implementation``?
|
|
|
|
|
|
2012-05-01 02:54:55 -04:00
|
|
|
|
Backward compatibility issues will make it difficult to change our
|
|
|
|
|
minds later.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-01 02:54:55 -04:00
|
|
|
|
The type we use ultimately depends on how general we expect the
|
|
|
|
|
consumption of ``sys.implementation`` to be. If its practicality is
|
|
|
|
|
oriented toward internal use then the data structure is not as
|
|
|
|
|
critical. However, ``sys.implementation`` is intended to have a
|
|
|
|
|
non-localized impact across the standard library and the
|
2012-05-06 05:17:25 -04:00
|
|
|
|
interpreter. It is better to *not* make hacking it become an
|
2012-05-01 02:54:55 -04:00
|
|
|
|
attractive nuisance, regardless of our intentions for usage.
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
* Should ``sys.implementation`` and its values be immutable? A benefit
|
|
|
|
|
of an immutable type is it communicates that the value is not
|
|
|
|
|
expected to change and should not be manipulated.
|
|
|
|
|
|
|
|
|
|
* Should ``sys.implementation`` be strictly disallowed to have methods?
|
|
|
|
|
Classes often imply the presence (or possibility) of methods, which
|
|
|
|
|
may be misleading in this case.
|
|
|
|
|
|
|
|
|
|
* Should ``sys.implementation`` implement the collections.abc.Mapping
|
|
|
|
|
interface?
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implementation
|
|
|
|
|
==============
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
The implementation of this PEP is covered in `issue #14673`_.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
References
|
|
|
|
|
==========
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. [#original] The 2009 sys.implementation discussion:
|
|
|
|
|
http://mail.python.org/pipermail/python-dev/2009-October/092893.html
|
|
|
|
|
|
|
|
|
|
.. [#revived] The initial 2012 discussion:
|
|
|
|
|
http://mail.python.org/pipermail/python-ideas/2012-April/014878.html
|
|
|
|
|
|
|
|
|
|
.. [#feedback] Feedback on the PEP:
|
|
|
|
|
http://mail.python.org/pipermail/python-ideas/2012-April/014954.html
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. [#guess] The ``platform`` code which divines the implementation name:
|
|
|
|
|
http://hg.python.org/cpython/file/2f563908ebc5/Lib/platform.py#l1247
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. [#cachetag] The definition for cache tags in PEP 3147:
|
|
|
|
|
http://www.python.org/dev/peps/pep-3147/#id53
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. [#tag_impl] The original implementation of the cache tag in CPython:
|
|
|
|
|
http://hg.python.org/cpython/file/2f563908ebc5/Python/import.c#l121
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. [#tests] Examples of implementation-specific handling in test.support:
|
|
|
|
|
* http://hg.python.org/cpython/file/2f563908ebc5/Lib/test/support.py#l509
|
|
|
|
|
* http://hg.python.org/cpython/file/2f563908ebc5/Lib/test/support.py#l1246
|
|
|
|
|
* http://hg.python.org/cpython/file/2f563908ebc5/Lib/test/support.py#l1252
|
|
|
|
|
* http://hg.python.org/cpython/file/2f563908ebc5/Lib/test/support.py#l1275
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. [#os_name] The standard library entry for os.name:
|
|
|
|
|
http://docs.python.org/3.3/library/os.html#os.name
|
|
|
|
|
|
|
|
|
|
.. [#javatest] The use of ``os.name`` as 'java' in the stdlib test suite.
|
|
|
|
|
http://hg.python.org/cpython/file/2f563908ebc5/Lib/test/support.py#l512
|
|
|
|
|
|
|
|
|
|
.. [#Nick] Nick Coghlan's proposal for ``sys.implementation.metadata``:
|
|
|
|
|
http://mail.python.org/pipermail/python-ideas/2012-May/014984.html
|
2012-05-01 02:51:22 -04:00
|
|
|
|
|
2012-04-27 17:32:38 -04:00
|
|
|
|
.. _issue #14673: http://bugs.python.org/issue14673
|
|
|
|
|
|
2012-05-01 02:51:22 -04:00
|
|
|
|
.. _Lib/test/support.py: http://hg.python.org/cpython/file/2f563908ebc5/Lib/test/support.py
|
|
|
|
|
|
2012-05-06 05:17:25 -04:00
|
|
|
|
.. _Python/import.c: http://hg.python.org/cpython/file/2f563908ebc5/Python/import.c
|
|
|
|
|
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
Copyright
|
|
|
|
|
=========
|
|
|
|
|
|
2012-05-01 02:54:55 -04:00
|
|
|
|
This document has been placed in the public domain.
|
2012-04-27 17:32:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-01 02:54:55 -04:00
|
|
|
|
..
|
|
|
|
|
Local Variables:
|
|
|
|
|
mode: indented-text
|
|
|
|
|
indent-tabs-mode: nil
|
|
|
|
|
sentence-end-double-space: t
|
|
|
|
|
fill-column: 70
|
|
|
|
|
coding: utf-8
|
|
|
|
|
End:
|