On Mon, Apr 30, 2012 at 3:04 PM, Barry Warsaw firstname.lastname@example.org wrote:
On Apr 27, 2012, at 12:36 AM, Eric Snow wrote:
``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)
That's a good point. Also, a dict better reflects a collection of variables that a dotted-access object, which to me implies the potential for methods as well.
OTOH, maybe we need a nameddict type!
You won't have to convince _me_. :)
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.).
Yeah, you got it. For CPython it would be "http://hg.python.org/cpython". You're right that vcs_url is more clear. I'll update it.
Perhaps I should clarify "Other Possible Values" in the PEP? I'd intended it as a list of meaningful names, most of which others had suggested, that could be considered at some later point. That's part of why I didn't develop the descriptions there too much. Rather, I wanted to focus on the two primary names for now.
Should those potential names be considered more seriously right now? I was hoping to keep it light to start out, just the things we'd use immediately.
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?
I was thinking along those lines. For CPython, it could be 76678 or ab63e874265e or both. The decision on any constraints for this one would be subject to further discussion.
build_toolchain identifies the tools used to build the interpreter.
As a tuple of free-form strings?
That would work. I expect it would depend on how it would be used.
url (or website) the URL of the implementation's site.
Maybe 'homepage' (another Debian analog).
Sounds good to me.
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. ;)
Yeah, it's not so clear there. For Jython it would be something like "jvm X.X", for IronPython it would be ".net CLR X.X" or whatever. Again the actual definition would be subject to more discussion relative to the use case, be it information or otherwise.
gc_type the type of garbage collection used.
Another free-form string? What would be the values say, for CPython and Jython?
I was imagining a free-form string, like "reference counting" or "mark and sweep". I just depends on what people need it for.
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.
That's the way I'm leaning. I've covered it a little more in the newer version of the PEP (on python-ideas).
- 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.
Yeah, it's definitely not the focus of the PEP, but I think it's a valid long-term goal of which we should be cognizant.
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`_.
Nicely done! Let's see how those placeholders shake out.
Thanks. I'm glad to get this rolling. And yeah, I need to poke the folks with the other implementations to get their feedback (rather than rely on nods from 3 years ago). :)