On Apr 27, 2012, at 12:36 AM, Eric Snow wrote:
I've written up a PEP for the sys.implementation idea. Feedback is welcome!
Thanks for working on this PEP, Eric!
``sys.implementation`` is a dictionary, as opposed to any form of "named" tuple (a la ``sys.version_info``). This is partly because it doesn't have meaning as a sequence, and partly because it's a potentially more variable data structure.
I agree that sequence semantics are meaningless here. Presumably, a dictionary is proposed because this cache_tag = sys.implementation.get('cache_tag') is nicer than cache_tag = getattr(sys.implementation, 'cache_tag', None) OTOH, maybe we need a nameddict type!
repository the implementation's repository URL.
What does this mean? Oh, I think you mean the URL for the VCS used to develop this version of the implementation. Maybe vcs_url (and even then there could be alternative blessed mirrors in other vcs's). A Debian analog are the Vcs-* header (e.g. Vcs-Git, Vcs-Bzr, etc.).
repository_revision the revision identifier for the implementation.
I'm not sure what this is. Is it like the hexgoo you see in the banner of a from-source build that identifies the revision used to build this interpreter? Is this key a replacement for that?
build_toolchain identifies the tools used to build the interpreter.
As a tuple of free-form strings?
url (or website) the URL of the implementation's site.
Maybe 'homepage' (another Debian analog).
site_prefix the preferred site prefix for this implementation.
runtime the run-time environment in which the interpreter is running.
I'm not sure what this means either. ;)
gc_type the type of garbage collection used.
Another free-form string? What would be the values say, for CPython and Jython?
Version Format --------------
XXX same as sys.version_info?
Why not? :) It might be useful also to have something similar to sys.hexversion, which I often find convenient.
* What are the long-term objectives for sys.implementation?
- pull in implementation detail from the main sys namespace and elsewhere (PEP 3137 lite).
That's where this seems to be leaning. Even if it's a good idea, I bet it will be a long time before the old sys names can be removed.
* Alternatives to the approach dictated by this PEP?
* ``sys.implementation`` as a proper namespace rather than a dict. It would be it's own module or an instance of a concrete class.
Which might make sense, as would perhaps a top-level `implementation` module. IOW, why situate it in sys?
The implementatation of this PEP is covered in `issue 14673`_.
s/implementatation/implementation Nicely done! Let's see how those placeholders shake out. Cheers, -Barry