On Tue, May 1, 2012 at 8:37 PM, Nick Coghlan firstname.lastname@example.org wrote:
On Wed, May 2, 2012 at 11:09 AM, Steven D'Aprano email@example.com wrote:
Syntax-wise, dotted name access seems right to me for this, similar to sys.float_info. If you know a field exists, sys.implementation.field is much nicer than sys.implementation['field'].
I hate to admit it, but I'm starting to think that the right solution here is something like a dict with dotted name access.
Whereas I'm thinking it makes sense to explicitly separate out "standard, must be defined by all conforming Python implementations" and "implementation specific extras"
Under that model, we'd add an extra "metadata" field at the standard level to hold implementation specific fields. The initial set of standard fields would then be:
name: the name of the implementation (e.g. "CPython", "IronPython", "PyPy", "Jython") version: the version of the implemenation (in sys.version_info format) cache_tag: the identifier used by importlib when caching bytecode files in __pycache__ (set to None to disable bytecode caching) metadata: a dict containing arbitrary additional information about a particular implementation
sys.implementation.metadata would then give a home for information that needs to be builtin, without having to pollute the main sys namespace.
I really like this approach, particularly the separation aspect. Presumably sys.implementation would be more struct-like (static-ish, dotted-access namespace). I'll give it a day or two to stew and if it still seems like a good idea I'll weave it into the PEP.
One question though: having it be iterable (a la structseq or namedtuple) doesn't seem to be a good fit, but does it matter? Likewise with mutability. Thoughts?