[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