[Python-Dev] sys.implementation
Steven D'Aprano
steve at pearwood.info
Fri May 11 00:39:56 CEST 2012
Nick Coghlan wrote:
> On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Thu, 10 May 2012 11:33:14 +1000
>> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> The original concern (that sys.implementation may differ in length
>>> across implementations) has been eliminated by moving all
>>> implementation specific values into sys.implementation.metadata.
>> Uh. It's scary the kind of things people sometimes come up with :-)
>>
>> sys.implementation.metadata looks like a completely over-engineered
>> concept. Please, let's just make sys.implementation a dict and stop
>> bothering about ordering and iterability.
>
> Aye. Add a rule that all implementation specific (i.e. not defined in
> the PEP) keys must be prefixed with an underscore and I'm sold.
So now we're adding a new convention to single underscore names? Single
underscore names are implementation-specific details that you shouldn't use or
rely on, except in sys.implementation, where they are an optional part of the
public interface.
There are public keys which all Pythons are expected to support. There are
public keys which only some Pythons are expected to support. We may call them
"implementation-specific", but that refers to the PYTHON implementation, not
the implementation of sys.implementation. As far as sys.implementation is
concerned, these keys are public but optional, not private.
Hence labelling them with a single underscore overrides the convention that
_single underscore names are private, for one that they are public but optional.
I'm not so sure that this is a good idea.
To bike-shed a moment, if we're going to stick to a dict, and you really think
that it is important to have a naming convention to distinguish between
optional keys and those common to all Pythons, perhaps a better convention
would be to prefix the optional keys with a dot, or a dash. This introduces a
new convention without clashing with an existing one.
--
Steven
More information about the Python-Dev
mailing list