Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
> I can see that there are ways that I can change my tests. > I see that there are third-party libraries that can help me with this. Please do that. That is good design and uses all the tools the way they are meant to be used. > But changing the behavior of the standard library, without a > way to retain the old behavior, and asking people to adapt > by changing their test suites, seems a bit cavalier. Several thoughts: * We are not cavalier. We generally work very hard to preserve guaranteed behaviors. For example, see all the work done on version numbering random seeding or pickle versions. That said, we cannot be handcuffed by over-reliance on implementation details; otherwise, we wound never be able to improve the library. The whole point of encapsulation and abstraction is to provide freedom to improve the internals and add capabilities without breaking the API contract. * It is reasonable for folks to change tests which were flawed from the outset (just like when hash randomization was introduced, it scrambled key order and broke any tests that relied on key order). FWIW, we remove or fix fragile or ill conceived tests in our own test suite all the time. * We could add an option to sort attributes but this just clutters the API and turns an old quirk into a permanent fixture. Instead, I recommend adding a documentation link to a standards compliant canonicalization tool. > Let's honor Python's tradition of standard library stability, > and give me a way to keep the behavior I used to have. The library IS stable with respect to documented guaranteed behaviors. With respect to everything else, our tradition is make improvements where we can. We don't backport these changes so that mirco-releases retain their quirks. But point releases are allowed and encouraged to make improvements (i.e. this is for 3.8 and later). In this case, there was never an API contract to sort attributes. In a way, this is no different than when we improve a repr (see match objects for example). That would break tests that incorrectly relied on an exact output match. When a test stops matching what a tool does, the one that is incorrect is the one that should be changed. If there is an API contract, the tool needs to change to match. However, if the test is fundamentally flawed, it should be one to change. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34160> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
