Given that in Python 3000 you can now use ... as an expression, it seemed like its repr might as well be ... too. The thread quoted in pep 3100 as the reason for the decision suggested using '(int, ...)' as a type annotation; in such expressions, having ... print as ... would be more readable. Note that this would break any doctests including ellipses; none of the Lib/test tests do, and the non-doctests don't care about the repr and still pass. Since prior to Python 3000 ... could only be used in slices, it's unlikely this will break much. I have now written about 100 times more characters than are changed by the patch.
(Continuing to talk to myself) It's funny, I mentioned doctest already, thinking just that 'Ellipsis' would now print as '...' and the difference would cause incompatibilities; i.e. the same problem you get any time a __repr__ changes. But there's a worse problem, which is that '...' looks almost exactly like sys.PS2, so a doctest like this will mistake the output for a continuation line and fail: """ >>> Ellipsis ... """ ********************************************************************** File "./doctesterr.py", line 6, in __main__ Failed example: Ellipsis Expected nothing Got: ... ********************************************************************** In light of which grossness this trivial patch is probably not worth it.
Let's not do this. When I type this at the prompt at least I get a response that might help me understand what's going on: >>> ... Ellipsis >>> Imagine someone's surprise with this session though: >>> ... ... >>>
