[Python-ideas] PEP 4XX: Adding sys.implementation
Nick Coghlan
ncoghlan at gmail.com
Tue May 1 04:57:49 CEST 2012
On Tue, May 1, 2012 at 12:39 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Sat, Apr 28, 2012 at 12:22 AM, Chris Rebert <pyideas at rebertia.com> wrote:
>> On Fri, Apr 27, 2012 at 11:06 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>>>
>>> * ``sys.implementation`` as a proper namespace rather than a dict. It
>>> would be it's own module or an instance of a concrete class.
>>
>> So, what's the justification for it being a dict rather than an object
>> with attributes? The PEP merely (sensibly) concludes that it cannot be
>> considered a sequence.
>
> 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.
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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list