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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4