[Python-Dev] sys.implementation (original) (raw)

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