Enhancing range object string displays

On the bug tracker, there is a proposal to enhance range objects so that printing them will display a snapshot of the values included, including the end points. For example: print(range(10)) currently displays "range(10)". The proposal is for the __str__ method to instead return "<range object [0, 1, ..., 8, 9]>". https://bugs.python.org/issue35200 print(range(2, 200, 3)) would display <range object [2, 5, ..., 194, 197]> Note that the original proposal was for range objects' __repr__ to display this behaviour. But given the loss of eval(repr(obj)) round tripping, and the risk of breaking backwards compatibility, it was decided that isn't acceptable but using the same display for __str__ (and hence produced by print) would be nearly as useful but without the downsides. The developer who proposed the feature, Julien, now wants to reject the feature request. I think it is still a useful feature for range objects. What do others think? Is this worth re-opening? -- Steve

I think it is kind of useless effort. If somebody using range() then probably knows about it. Also there are some workarounds inspect range() result already. Like: *range(10) or if it is big: *range(10000000)[:10] On Mon, Nov 19, 2018 at 4:25 PM Steven D'Aprano <steve@pearwood.info> wrote:

On Mon, Nov 19, 2018 at 05:09:25PM -0800, danish bluecheese wrote:
I think it is kind of useless effort. If somebody using range() then probably knows about it.
For experienced users, sure, but this is an enhancement to help beginners who may be confused by the half-open end points. Even non-beginners may find it nice to be able to easily see the end points when the step size is not 1. If range objects had this, I'd use it in the REPL to check the end points. Sure, I could convert to a list and take a slice, but giving the object a nicer print output makes less work for the user. -- Steve

On Tue, Nov 20, 2018 at 1:10 PM Steven D'Aprano <steve@pearwood.info> wrote:
I'm a fairly experienced Python programmer, and I still just fire up a REPL to confirm certain uses of range() with steps. What would it be like if the string form looked like this:
range(1, 30, 3) range([1, 4, 7, ..., 25, 28])
In theory, this could actually be made legal, and could be a cool feature for an enhanced REPL to support. (All you have to do is define 'range' as a function that checks if it's been given a list, and if not, passes it on unchanged.) Whether this form or the original, I think this would be an improvement. ChrisA

On Tue, 20 Nov 2018 at 02:23, Chris Angelico <rosuav@gmail.com> wrote:
Wouldn't that use the repr, which is *not* changing in this proposal?
I do like the improved display, but I don't know how useful it would be in practice, given that I don't *often* use raw range objects (as opposed to "for x in range(...)") and the default repr display won't change. I am inclined to think that we're overthinking the problem - changing the str() of a range object is unlikely to break anything, is a small but clear usability improvement, and more time has probably been spent debating whether it's a good idea than it would have cost to just make the change... Paul

On Mon, Nov 19, 2018 at 6:09 PM Steven D'Aprano <steve@pearwood.info> wrote:
I feel like the kind of users who would benefit the most from this are exactly the same users who are baffled by the distinction between str() and repr() and which one is used when, and thus would struggle to benefit from it? -n -- Nathaniel J. Smith -- https://vorpus.org

I think it is kind of useless effort. If somebody using range() then probably knows about it. Also there are some workarounds inspect range() result already. Like: *range(10) or if it is big: *range(10000000)[:10] On Mon, Nov 19, 2018 at 4:25 PM Steven D'Aprano <steve@pearwood.info> wrote:

On Mon, Nov 19, 2018 at 05:09:25PM -0800, danish bluecheese wrote:
I think it is kind of useless effort. If somebody using range() then probably knows about it.
For experienced users, sure, but this is an enhancement to help beginners who may be confused by the half-open end points. Even non-beginners may find it nice to be able to easily see the end points when the step size is not 1. If range objects had this, I'd use it in the REPL to check the end points. Sure, I could convert to a list and take a slice, but giving the object a nicer print output makes less work for the user. -- Steve

On Tue, Nov 20, 2018 at 1:10 PM Steven D'Aprano <steve@pearwood.info> wrote:
I'm a fairly experienced Python programmer, and I still just fire up a REPL to confirm certain uses of range() with steps. What would it be like if the string form looked like this:
range(1, 30, 3) range([1, 4, 7, ..., 25, 28])
In theory, this could actually be made legal, and could be a cool feature for an enhanced REPL to support. (All you have to do is define 'range' as a function that checks if it's been given a list, and if not, passes it on unchanged.) Whether this form or the original, I think this would be an improvement. ChrisA

On Tue, 20 Nov 2018 at 02:23, Chris Angelico <rosuav@gmail.com> wrote:
Wouldn't that use the repr, which is *not* changing in this proposal?
I do like the improved display, but I don't know how useful it would be in practice, given that I don't *often* use raw range objects (as opposed to "for x in range(...)") and the default repr display won't change. I am inclined to think that we're overthinking the problem - changing the str() of a range object is unlikely to break anything, is a small but clear usability improvement, and more time has probably been spent debating whether it's a good idea than it would have cost to just make the change... Paul

On Mon, Nov 19, 2018 at 6:09 PM Steven D'Aprano <steve@pearwood.info> wrote:
I feel like the kind of users who would benefit the most from this are exactly the same users who are baffled by the distinction between str() and repr() and which one is used when, and thus would struggle to benefit from it? -n -- Nathaniel J. Smith -- https://vorpus.org
participants (6)
-
Chris Angelico
-
danish bluecheese
-
MRAB
-
Nathaniel Smith
-
Paul Moore
-
Steven D'Aprano