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

[Eric Snow]

On Mon, Apr 30, 2012 at 8:57 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, May 1, 2012 at 12:39 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> At this point I'm not aware of the strong justifications either way.
>> However, sys.implementation is currently intended as a simple
>> collection of variables.  A dict reflects that.
>>
>> One obvious concern is that if we start off with a dict we're binding
>> ourselves to that interface.  If we later want concrete class with
>> dotted lookup, we'd be looking at backwards-incompatibility.  This is
>> the part of the PEP that still needs more serious thought.
>
> I think it's a case where practicality beats purity. By using
> structseq, we get a nice representation and dotted attribute access,
> just as we have for sys.float_info. Providing this kind of convenience
> is the same reason collections.namedtuple exists.

That was my original sentiment, partly for the "this is how it's
already been done" aspect.  Barry made a good point about
sys.implementation.get(name) vs. getattr(sys.implementation, name,
None).  However, having dotted access still seems more correct.
(continued below...)

> We should just document that the length of the tuple and the order of
> items is not guaranteed (either across implementations or between
> versions), and even the ability to iterate over the items or access
> them by index is not mandatory in an implementation. Would it be
> better if we had a separate "namespace" type in CPython that simply
> *disallowed* iteration and indexing? Perhaps, but we've survived long
> enough without it that I have my doubts about the practical need.

That's a good point.  Perhaps it depends on how general we expect the
consumption of sys.implementation to be.  If its practicality is
oriented toward internal use then the data structure is not as
critical.  However, sys.implementation is intended to have a
non-localized impact across the standard library and the interpreter.
I'd rather not make hacking it become an attractive nuisance,
regardless of our intentions for usage.

This is where I usually defer to those that have been dealing for
<non-trivial #> years with the aftermath of these types of decisions.
<wink>

-eric