[Python-Dev] sys.implementation

[Scott Dial]

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