Eric Snow's latest update.
This commit is contained in:
Barry Warsaw
parent
b5d1d94750
commit
99d6530667
113
pep-0421.txt
113
pep-0421.txt
|
|
@ -98,7 +98,9 @@ implementers must define them:
|
|||
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`_.
|
||||
Also see the list of `Example Metadata Values`_. ``metadata`` is a
|
||||
dictionary. While a mutable type, neither it nor its items will
|
||||
change (as already noted). Likewise they should not be modified.
|
||||
|
||||
|
||||
Adding New Required Attributes
|
||||
|
|
@ -141,8 +143,8 @@ the process described in `Adding New Required Attributes`_.
|
|||
project.
|
||||
|
||||
**vcs_revision_id**
|
||||
A value that identifies the VCS revision of the implementation that
|
||||
is currently running.
|
||||
A value that identifies the VCS revision of the implementation
|
||||
that is currently running.
|
||||
|
||||
**build_toolchain**
|
||||
Identifies the tools used to build the interpreter.
|
||||
|
|
@ -182,18 +184,18 @@ makes explicit that which was implicit.
|
|||
Why a Custom Type?
|
||||
------------------
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The alternatives to a dictionary are considered separately here:
|
||||
|
||||
**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``.
|
||||
maps names to values and that's all. It also reflects the more
|
||||
variable nature of ``sys.implementation``.
|
||||
|
||||
However, a simple dictionary does not set expectations very well about
|
||||
the nature of ``sys.implementation``. The custom type approach, with
|
||||
|
|
@ -217,9 +219,9 @@ Fallback lookup may favor dicts::
|
|||
|
||||
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.
|
||||
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.
|
||||
|
||||
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
|
||||
|
|
@ -290,10 +292,10 @@ platform.python_implementation()
|
|||
|
||||
"explicit is better than implicit"
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
|
|
@ -359,26 +361,43 @@ 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.
|
||||
special case. Currently Jython sets os._name for the normal os.name
|
||||
value.
|
||||
|
||||
|
||||
Feedback From Other Python Implementers
|
||||
Feedback From Other Python Implementors
|
||||
=======================================
|
||||
|
||||
IronPython
|
||||
----------
|
||||
|
||||
XXX
|
||||
Jeff Hardy responded to a request for feedback [#ironpython]_. He
|
||||
said, "I'll probably add it the day after it's approved"
|
||||
[#jeff_hardy_2012]_. He also gave useful feedback on both the type of
|
||||
``sys.implementation`` and on the ``metadata`` attribute.
|
||||
|
||||
Jython
|
||||
------
|
||||
|
||||
XXX
|
||||
In 2009 Frank Wierzbicki said this (relative to Jython implementing the
|
||||
required attributes) [#frank_wierzbicki_2009]_::
|
||||
|
||||
Speaking for Jython, so far it looks like something we would adopt
|
||||
soonish after it was accepted (it looks pretty useful to me).
|
||||
|
||||
PyPy
|
||||
----
|
||||
|
||||
XXX
|
||||
Some of the PyPy developers have responded to a request for feedback
|
||||
[#pypy]_. Armin Rigo said the following [#armin_rigo_2012]_::
|
||||
|
||||
For myself, I can only say that it looks like a good idea, which we
|
||||
will happily adhere to when we migrate to Python 3.3.
|
||||
|
||||
He also expressed support for keeping the required list small. Both
|
||||
Armin and Laura indicated that an effort to better catalog Python's
|
||||
implementation would be welcome. Such an effort, for which this PEP is
|
||||
a small start, will be considered separately.
|
||||
|
||||
|
||||
Past Efforts
|
||||
|
|
@ -402,6 +421,27 @@ helping to make it friendlier to alternate implementations. PEP 421
|
|||
is proposed in that same spirit.
|
||||
|
||||
|
||||
The Bigger Picture
|
||||
==================
|
||||
|
||||
It's worth noting again that this PEP is a small part of a larger
|
||||
on-going effort to identify the implementation-specific parts of Python
|
||||
and mitigate their impact on other implementations than CPython.
|
||||
|
||||
``sys.implementation`` is a focal point for implementation-specific
|
||||
data, acting as a nexus for cooperation between the language, the
|
||||
standard library, and the different implementations. As time goes by
|
||||
it is feasible that ``sys.implementation`` will assume current
|
||||
attributes of ``sys`` and other builtin/stdlib modules, where
|
||||
appropriate. In this way, it is a PEP 3137-lite, but starting as
|
||||
small as possible.
|
||||
|
||||
However, as already noted, many other efforts predate
|
||||
``sys.implementation``. Neither is it necessarily a major part of the
|
||||
effort. Rather, consider it as part of the infrastructure of the
|
||||
effort to make Python friendler to alternate implementations.
|
||||
|
||||
|
||||
Alternatives
|
||||
============
|
||||
|
||||
|
|
@ -412,11 +452,6 @@ straightforward, no alternatives have been considered for this PEP.
|
|||
Open Issues
|
||||
===========
|
||||
|
||||
* What are the long-term objectives for ``sys.implementation``?
|
||||
|
||||
- possibly pull in implementation details from the main ``sys``
|
||||
namespace and elsewhere (PEP 3137 lite).
|
||||
|
||||
* What is the process for introducing new required variables? PEP?
|
||||
|
||||
* Is the ``sys.version_info`` format the right one here?
|
||||
|
|
@ -427,8 +462,6 @@ Open Issues
|
|||
reflect the version of the language spec? Micro version, series,
|
||||
and release seem like implementation-specific values.
|
||||
|
||||
* Alternatives to the approach dictated by this PEP?
|
||||
|
||||
* Do we really want to commit to using a dict for
|
||||
``sys.implementation``?
|
||||
|
||||
|
|
@ -468,11 +501,33 @@ References
|
|||
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
|
||||
http://mail.python.org/pipermail/python-ideas/2012-March/014555.html
|
||||
(and 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
|
||||
|
||||
.. [#ironpython] Feedback from the IronPython developers:
|
||||
http://mail.python.org/pipermail/ironpython-users/2012-May/015980.html
|
||||
|
||||
.. [#dino_viehland_2009] (2009) Dino Viehland offers his opinion:
|
||||
http://mail.python.org/pipermail/python-dev/2009-October/092894.html
|
||||
|
||||
.. [#jeff_hardy_2012] (2012) Jeff Hardy offers his opinion:
|
||||
http://mail.python.org/pipermail/ironpython-users/2012-May/015981.html
|
||||
|
||||
.. [#jython] Feedback from the Jython developers:
|
||||
???
|
||||
|
||||
.. [#frank_wierzbicki_2009] (2009) Frank Wierzbicki offers his opinion:
|
||||
http://mail.python.org/pipermail/python-dev/2009-October/092974.html
|
||||
|
||||
.. [#pypy] Feedback from the PyPy developers:
|
||||
http://mail.python.org/pipermail/pypy-dev/2012-May/009883.html
|
||||
|
||||
.. [#armin_rigo_2012] (2012) Armin Rigo offers his opinion:
|
||||
http://mail.python.org/pipermail/pypy-dev/2012-May/009884.html
|
||||
|
||||
.. [#guess] The ``platform`` code which divines the implementation name:
|
||||
http://hg.python.org/cpython/file/2f563908ebc5/Lib/platform.py#l1247
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue