[Python-Dev] sys.implementation (original) (raw)
Scott Dial scott+python-dev at scottdial.com
Thu May 10 17:34:41 CEST 2012
- Previous message: [Python-Dev] sys.implementation
- Next message: [Python-Dev] sys.implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 scott at scottdial.com
- Previous message: [Python-Dev] sys.implementation
- Next message: [Python-Dev] sys.implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]