On Saturday, December 26, 2015 8:48 AM, Wes Turner <wes.turner@gmail.com> wrote:
So,
Would I be correct in that, because of this regression in __repr__ behavior (elipsis instead of total information) from 2.x to 3.x, any tests that string compare __repr__ are now off?
No. 2.x did not provide total information. It used the exact same __repr__ as 3.x. (If you can come up with a way to provide total information that's readable to both humans and the parser, I'm sure everyone would love to see it.) Any tests that string compare __repr__ to test the equality of two lists in 2.x will get the same results in 3.x. They're still probably bad tests, but no worse than before. The only difference is that the `...` is a valid literal in 3.x, so `[1, 2, [...]]` is a valid list display in 3.x, and it wasn't in 2.x. (Even there, tests that assume __repr__ equality are no more broken than before: a list containing 1, 2, and itself reprs as `[1, 2, [...]]`, while a list containing 1, 2, and a list containing `...` reprs as `[1, 2, [Ellipsis]]`, so they will not be mistakenly compared equal.) As Serhiy points out, there actually _is_ a regression here: tests that depend on the fact that a circular list will raise a SyntaxError on eval(repr(x)) do break with 3.0. I doubt there were many such tests, given that nobody's noticed the problem until half a decade later, but I suppose that is a regression. At any rate, I think what people are actually worried about here is not the theoretical chance that such a regression might have happened 5 years ago, but the more practical fact that 3.x might be misleading to human beings in cases where 2.x wasn't. For example, if you mostly do 3.x NumPy stuff, you're used to passing ellipses around, and maybe even storing them in index arrays, but you rarely if ever see a circular list. So, when you see, say, `[[1], [2], [...]]` on the REPL, you may misinterpret it as meaning something different from what it does.