On Thu, May 3, 2012 at 2:20 AM, M.-A. Lemburg email@example.com wrote:
Some corrections to the PEP text:
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 . 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 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.
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.