[Python-ideas] PEP 4XX: Adding sys.implementation

[Eric Snow]

On Thu, May 3, 2012 at 2:20 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Some corrections to the PEP text:
>
> platform.python_implementation()
> --------------------------------
>
> The following text in the PEP needs to be updated:
>
> """
> The platform module guesses the python implementation by looking for
> clues in a couple different sys variables [3]. However, this approach
> is fragile.
> """
>
> Fact is, that sys.version parsing is documented to be done by the
> platform module (see the docs on sys.version), so implementations
> are free to provide patches in case they choose different ways of
> formatting sys.version.
>
> A sys.implementation record would make things easier for the platform
> module, though, so it's an improvement.

Yeah, I'll update that to be softer and more clear.

> sys.version
> -----------
>
> sys.version is defined as "A string containing the version number
> of the Python interpreter plus additional information on the build
> number and compiler used. This string is displayed when the interactive
> interpreter is started. Do not extract version information out of it,
> rather, use version_info and the functions provided by the platform module.
>
> It's not defined as "version of the Python language" as the PEP
> appears to indicate.

This is an excellent point.  sys.(version|version_info|hexversion)
reflect CPython specifics, rather than the language itself.  As far as
I know the language does not have a "micro" version, nor a release
level or serial.

So where does that leave us?  Undoubtedly no small number of people
already depend on the the sys variables for CPython release info, so
we can't just change the semantics.  I'll clarify the PEP and add this
to the open issues list because the PEP definitely needs to be clear
here.  Any suggestions on this point would be great.

> Other things:
>
> Making sys.implementation a dictionary
> --------------------------------------
>
> This is not a good idea, since it allows for monkey-patching
> the values and will also result in new undocumented or per-implementation
> keys.
>
> Better use a namedtuple like we do for all other such informational
> resources.

Nick Coghlan made good suggestion on this front that I'm likely going
to adopt: sys.implementation as an object (namespace with dotted
access) with required attributes.  One required attribute would be
'metadata', a dict where optional/per-implementation values could go.

Having it be immutable (make monkey-patching hard) didn't seem like it
mattered, though I'm not opposed.  I just don't see that as a
convincing reason for it to be a named tuple (structseq, etc.).

To be honest, I'd like to avoid making sys.implementation any kind of
sequence.  It has no meaning as a sequence (hence why the PEP shifted
from named tuple to dict).  Unlike other informational sources, we
expect that the namespace of required attributes will grow over time.
As such, people shouldn't rely on a fixed number of attributes, which
a named tuple would imply.  As well, I'm not convinced that the order
of the attributes is significant, nor that sequence unpacking is
useful here.

So in order to send the right message on both points, I'd rather not
make it a sequence.  It *could* be meaningful to implement the Mapping
ABC, but I'm not going to specify that in the PEP without good reason.
 (I will add that as an open issue though.)

Unless there is a good reason to use a named tuple, as opposed to a
regular object, let's not.  However, I'm still quite open to hearing
out arguments on this point.

-eric