On Tue, May 1, 2012 at 12:39 PM, Eric Snow email@example.com wrote:
On Sat, Apr 28, 2012 at 12:22 AM, Chris Rebert firstname.lastname@example.org wrote:
On Fri, Apr 27, 2012 at 11:06 PM, Eric Snow email@example.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.