Nick Coghlan wrote:
On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
On Thu, 10 May 2012 11:33:14 +1000
Nick Coghlan <ncogh...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
