On Mon, Apr 30, 2012 at 8:57 PM, Nick Coghlan email@example.com wrote:
On Tue, May 1, 2012 at 12:39 PM, Eric Snow firstname.lastname@example.org 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>