[Python-Dev] sys.implementation
Steven D'Aprano
steve at pearwood.info
Fri May 11 00:45:42 CEST 2012
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
More information about the Python-Dev
mailing list