[Python-ideas] PEP 4XX: Adding sys.implementation

[Eric Snow]

On Mon, Apr 30, 2012 at 3:04 PM, Barry Warsaw <barry at python.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.

>>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.

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`_.
>
> s/implementatation/implementation

Got it.

> 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). :)

-eric