Home Original page

[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