Scott Dial wrote:
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).
As opposed to unordered types when you add a new field? I don't think so.
When you add new fields, you can break tests *regardless* of whether the type
is ordered or unordered. If you change the public interface to a type, you
have to change any tests that rely on it.
But unordered types have a tendency to break tests even when you don't add new
fields (at least doctests), simply because their display can arbitrarily change.
Given the choice between having to re-write tests once in a blue moon when
there is a backwards-incompatible change to a type, and having tests randomly
break every time I run them because the display is unpredictable, I know which
one I prefer.
+1 to Nick's request for a PEP.
--
Steven
_______________________________________________
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
