On 5/10/2012 1:40 AM, Nick Coghlan wrote: > Unordered types can be a PITA for testing, for display and for generic > serialisation, so I definitely want to see a PEP before we add a new > one that basically has its sole reason for existence being "you can > iterate over and index the field values in a namedtuple". >
I could use those same arguments (testing, display, and generic serialization) as reasons /against/ using an ordered type (when it's not the intent of the author that it be ordered). That is: - Testing: This is an attractive nuisance because adding fields later can break the tests if the author of the type had no intent on the ordering being guaranteed (or the number of fields). - Display: If the author of the type didn't intend on the ordering being guaranteed, then the display could become nonsense when changing versions (e.g., upgrading a 3rd-party library). - Generic Serialization: Again, if the author didn't plan for that, then they could add additional fields or re-arrange them in a way that makes naive serialization give incorrect instances. The point is that the author of the type can't protect you from these mistakes if a namedtuple is used. The only tool the author of the type has at their disposal to warn you of your ways is documentation. If the type doesn't support iteration or indexing, then you are forced to do it right, because it's the only way that works. Furthermore, what is wrong with a repr that yields a dict-like string "record(a=1, b=2, c=3)" with regard to testing and display? -- Scott Dial sc...@scottdial.com _______________________________________________ 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
