[issue35200] Range repr could be better

2018-11-11 Thread Steven D'Aprano
Steven D'Aprano added the comment: > I've never seen any student try `str(range(10))` in the repl I never suggested that students would try calling str() directly. That would be silly. They would use print(), as I'm sure many of them are already doing. After 20+ years of using Python, I sti

[issue35200] Range repr could be better

2018-11-11 Thread Julien Palard
Julien Palard added the comment: I understand we like round-tripping represnetations, I think we like them because in much cases it's immediatly and unambiguously understandable by a Python developer. It's the best representation as it's the one conveying the most information. But `range(0,

[issue35200] Range repr could be better

2018-11-11 Thread Nick Coghlan
Nick Coghlan added the comment: I agree with Steven and Raymond on this one: changing __repr__ on ranges in a way that breaks round-tripping through eval would be problematic, especially as I'd expect that to be an issue in doctests as well. However, I also like the idea of having easier acc

[issue35200] Range repr could be better

2018-11-09 Thread Steven D'Aprano
Steven D'Aprano added the comment: With the proposed design, any two empty range objects have the same repr: repr(range(0)) == repr(range(2, 2)) == repr(range(1, 5, -1)) etc. Between this loss of information, and the loss of round-tripping through eval, I'm against this proposal. But I'd per

[issue35200] Range repr could be better

2018-11-09 Thread Raymond Hettinger
Raymond Hettinger added the comment: One other thought, since the current repr round-trips, it can be eval'd. So changing it might break some code. -- ___ Python tracker ___

[issue35200] Range repr could be better

2018-11-09 Thread Jules Lasne
Jules Lasne added the comment: As you can see in his PR (https://github.com/python/cpython/pull/10436), he added multiple display types based on the size of the range. This is easily represented in the dumb_range_repr function: https://github.com/python/cpython/pull/10436/files#diff-95a46658

[issue35200] Range repr could be better

2018-11-09 Thread Steven D'Aprano
Steven D'Aprano added the comment: Not everyone knows the '...' convention. At least according to Google's predictive search, if I type "what does three dots" I get common searches such as "what does three dots mean at the end of a sentence" and similar. How does your proposed repr look for

[issue35200] Range repr could be better

2018-11-09 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: If possible, I prefer to get the repr in the form of Python expression rather of cryptic angled form. The former is often shorter, that is important if it is a part of the repr of more complex object. You can just copy, paste and edit it. -- _

[issue35200] Range repr could be better

2018-11-09 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Or just >>> *range(1000, 2000, 100), (1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900) -- nosy: +serhiy.storchaka ___ Python tracker __

[issue35200] Range repr could be better

2018-11-09 Thread Raymond Hettinger
Raymond Hettinger added the comment: The current repr is awkward for teaching but does have the virtue of being able to round-trip. When that is possible, it is what the language usually chooses. FWIW, you can show ranges with print() and *-unpacking: >>> print(*range(1000, 2000, 100))

[issue35200] Range repr could be better

2018-11-09 Thread Lasne
Lasne added the comment: Sounds like a great idea to me, hence I never really understood how range worked -- nosy: +seluj78 ___ Python tracker ___

[issue35200] Range repr could be better

2018-11-09 Thread Julien Palard
Change by Julien Palard : -- keywords: +patch pull_requests: +9710 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue35200] Range repr could be better

2018-11-09 Thread Julien Palard
New submission from Julien Palard : This morning I was teaching Python (again and again), and again I was thinking we could do better about the representation of ranges. Typically in the current repr of ranges we do not see that the end is excluded: >>> range(10) range(0, 10) However it has