This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Introspectable range objects
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: daniel.urban, eric.araujo, ezio.melotti, mark.dickinson, pitrou, python-dev, rhettinger, smarnach, terry.reedy
Priority: normal Keywords: patch

Created on 2010-09-18 18:39 by daniel.urban, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
range_attrs.diff daniel.urban, 2010-09-18 18:39 Patch adding the start, stop and step attributes to range
range_attrs_2.patch daniel.urban, 2011-04-17 11:51 Updated patch review
range_attrs_3.patch daniel.urban, 2011-04-19 21:06 Corrected patch following Éric's comments review
Messages (13)
msg116824 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2010-09-18 18:39
The attached patch adds the start, stop and step members to range objects, corresponding the contructor arguments. The patch also include tests and documentation changes.
msg116836 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-09-18 23:02
I don't see anything wrong with this idea, but I don't really see a need for it either.  AFAICT, this has never been requested in the 20 years that range() has been in Python.  This is probably YAGNI.  It may also be in violation of the language moratorium (it's one more thing that other implementations would have to mirror).
msg116839 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-09-18 23:15
One other thought.  If there is a perceived need, I would rather an alternate approach that unifies a language a bit by letting range() expose its arguments as a slice and modify its input to accept a slice.

>>> range(0, 20, 2).slice
slice(0, 20, 20)
>>> range(_)
range(0, 20, 2)

>>> s = range(0, 20, 2).slice
>>> s.start
>>> s.stop
>>> s.step
msg116846 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-19 01:08
What is the use case for this?
msg116853 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2010-09-19 09:44
> What is the use case for this?

The basic idea was, that in Python almost everything is introspectable, so why range objects aren't.  It was pretty straightforward to implement it, so I've done it (actually when I was working on rangeobject.c, I was surprised to see that these members aren't available from python code).
But if this isn't needed, I'm absolutely ok with that.  I think this would be a nice to have feature, but of course not necessary.  Also, if it violates the moratorium (I don't know), then of course this sould be at least postponed.
msg117330 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-09-24 20:40
Range objects are new in 3.0; they supersede 2.x xrange objects, which are perhaps 10 years old. I do not remember that xrange objects had such attributes. On the other hand, I believe there were requests.

The request, with either implementation, seems reasonable in that range objects could be regarded as iterable slice objects. The differences are that range objects have __getitem__, __iter__, and __reversed__ special methods while slice objects have start, stop, and stop real-only attributes and the indices method. (I could not really understand the last from the doc; I had to experiment.) Starting fresh, we might do with just one class instead of two.

I guess this makes me +0.3 at the moment.
msg117366 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-25 13:32
> One other thought.  If there is a perceived need, I would rather an
> alternate approach that unifies a language a bit by letting range()
> expose its arguments as a slice and modify its input to accept a slice.

This sounds like an obscure complication to me. A range is not a slice and I don't see the point of trying to bridge both concepts. It is even more YAGNI than the original request.
msg133921 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2011-04-17 11:51
Now that the moratorium has already ended, I'll try again.  I've updated the patch.

It seems, that this idea has already came up in the past: Guido in msg70525 said: "I also think ranges should be introspectable, exposing their start, stop and step values just like slice objects."

A possible use case: the range slicing logic is quite complex (with a lot of corner cases).  It would be good, if this logic would be accessible from Python code, for example to compute a slice of a slice-like-thing.  Currently slicing a range object returns another range object, but there is no way to determine the bounds of this new object.
msg134067 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-04-19 15:33
Looks good, apart from the use of assertEquals (deprecated in favor of assertEqual).  I’d also remove “merely” from the doc addition.
msg134102 - (view) Author: Daniel Urban (daniel.urban) * (Python triager) Date: 2011-04-19 21:06
Thanks, I've corrected my patch.
msg145712 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-17 15:27
See also #13200.
msg147096 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-05 16:15
I think this is ready for commit.
msg147104 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-11-05 19:19
New changeset 4643be424293 by Benjamin Peterson in branch 'default':
add introspection to range objects (closes #9896)
Date User Action Args
2022-04-11 14:57:06adminsetgithub: 54105
2011-11-05 19:19:10python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg147104

resolution: fixed
stage: patch review -> resolved
2011-11-05 16:15:55eric.araujosetnosy: + smarnach
messages: + msg147096
2011-11-05 16:11:15eric.araujolinkissue13200 superseder
2011-10-17 15:27:36ezio.melottisetnosy: + ezio.melotti, - BreamoreBoy
messages: + msg145712
2011-04-19 21:06:56daniel.urbansetfiles: + range_attrs_3.patch

messages: + msg134102
2011-04-19 15:33:31eric.araujosetnosy: + eric.araujo
messages: + msg134067
2011-04-17 11:51:50daniel.urbansetfiles: + range_attrs_2.patch

messages: + msg133921
versions: + Python 3.3, - Python 3.2
2010-09-25 13:32:50pitrousetnosy: + pitrou
messages: + msg117366
2010-09-24 20:40:20terry.reedysetnosy: + terry.reedy

messages: + msg117330
stage: patch review
2010-09-19 09:44:43daniel.urbansetmessages: + msg116853
2010-09-19 01:08:50BreamoreBoysetnosy: + BreamoreBoy
messages: + msg116846
2010-09-18 23:15:38rhettingersetmessages: + msg116839
2010-09-18 23:02:14rhettingersetnosy: + rhettinger
messages: + msg116836
2010-09-18 21:06:40pitrousetnosy: + mark.dickinson
2010-09-18 18:39:25daniel.urbancreate