[Python-3000] range() issues

[Guido van Rossum]

On Sun, Apr 27, 2008 at 4:07 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Sat, Apr 26, 2008 at 2:49 PM, Facundo Batista
>  <facundobatista at gmail.com> wrote:
>
>
> >  Which should the range() definition be, in your words?
>
>  In terms of ABCs,  range(..) is a Sized Iterable in the current
>  implementation.  It is not a Sequence because it is not a Container
>  and does not support slicing.  The idea to support x in range(..) was
>  discussed last year [1]  and appears to have been accepted but not
>  implemented. I understand that slicing support is in the works. [2]
>
>  I believe it would make sense to turn range(..) into a Sequence.  Here
>  are my reasons:
>
>  1. It will be easy to explain what range(..) is: "a sequence of
>  integers from start to stop, excluding stop, skipping step".
>
>  2. There will be fewer 2 to 3 incompatibilities.
>
>  [1] http://mail.python.org/pipermail/python-3000/2007-July/009028.html
>  [2] http://bugs.python.org/msg65807

I'm -0 on this (and on other recent enhancements like indexing and the
proposed repr() enhancement).

The reason that I'm so lukewarm is that I don't expect there to be
much use for all this extra functionality. Teachers who want to show
their students what range(x, y, z) is can just cast it to a list.

The cost of the extra functionality: writing it, reviewing it, adding
unittests, documenting it, maintaining it, making sure it works on
64-bit machines, having Python book authors discuss it; and in
addition some extra baggage in the executable that is never needed
(but I think the other reasons are more compelling). There's a reason
the xrange() object didn't have all this extra baggage.

Remember, one of the goals of Py3k is to *shrink* the language so that
it will fit in your brain again. This thread seems to be going in the
opposite direction.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)