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 <[EMAIL PROTECTED]> wrote: > On Sun, Apr 27, 2008 at 4:07 AM, Alexander Belopolsky > <[EMAIL PROTECTED]> wrote: > > On Sat, Apr 26, 2008 at 2:49 PM, Facundo Batista > > <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
