[Python-3000] range() issues

[Guido van Rossum]

BTW, if you're looking for a term describing range() that's better
than set or sequence, how about "series"? It's a mathematical word
that matches pretty exactly. (More accurately, I believe it's an
algebraic series.)

On Mon, Apr 28, 2008 at 4:18 PM, Guido van Rossum <guido at python.org> wrote:
> 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/)
>



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