On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > Please, no. No new > just-like-a-namedtuple-except-you-can't-iterate-over-it type, and > definitely not one exposed in the collections module. > > We've been over this before: collections.namedtuple *is* the standard > library's answer for structured records. TOOWTDI, and the way we have > already chosen includes iterability as one of its expected properties. > > People shouldn't be so quick to throw away ordered iterability - it > makes a lot of things like generic display routines and serialisation > *much* easier, and without incurring the runtime cost of multiple > calls to sorted(). > > The original concern (that sys.implementation may differ in length > across implementations) has been eliminated by moving all > implementation specific values into sys.implementation.metadata. The > top-level record now has a consistent length for any given language > version. The fact that the length of the record may still change in > *future* versions of Python can be handled through documentation - we > can simply tell people "it's OK to iterate over the fields, and even > to use tuple unpacking, but if you want to future proof your code, > make sure to include the trailing ', *' to ignore any fields that get > added in the future".
Good point. I'd forgotten about that new tuple unpacking syntax. FYI, a named tuple was my original choice. I'm going to sit on this a few days though. Who knows, we might be back to using a dict by then. <wink> Key points: * has dotted access * is immutable Both reflect the nature of sys.implementation as currently described (a fixed set of attributes on an dotted-access namespace). > To help focus the discussion, I am going to propose a specific (albeit > still somewhat hypothetical) use case: a cross-implementation testing > system that wants to be able to consistently capture data about the > version of Python that was tested, *without* needing implementation > specific code in the metadata capture step. > > That produces the following set of requirements: > > 1. sys.implementation should be immutable for a given execution of Python > 2. repr(sys.implementation) should display all recorded details of the > implementation > 3. It should be possible to write a generic, future-proof, > serialisation of sys.implementation that captures all recorded details > > collections.namedtuple meets all those requirements (_structseq > doesn't meet the last one at this point, but more on that later) > > It also shows that we only need to place very minimal constraints on > sys.implementation.metadata: the type of that structure can be > entirely up to the implementation, with the only requirement being > that repr(sys.implementation.metadata) should produce a string that > accurately captures the stored information. The only > cross-implementation operation that is supported on that field would > be to take its representation. Nice. > Now, because this is going to be in the sys module, for CPython, we > would actually need to use _structseq rather than > collections.namedtuple. To do so in a useful way, _structseq should > get two new additions: > - the "_fields" attribute > - the "_asdict" method Sounds good to me regardless of the PEP. -eric _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
