On Mon, Apr 28, 2008 at 7:18 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: .. > 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.
I would say making range return a instance of Sequence will make that feature easier to understand. In the current implementation, given a range r, you can do r[0], but not r[0:2], or x in r; given n > sys.maxsize, you can create range(n), but the result is not indexable or sizable. I would say "range(n) is a memory efficient substitute for [0, 1, ... n-1]" is easier to fit into one's brain that the current hodgepodge of exceptions. in terms of implementation, slicing support does not add much complexity once indexing is supported. If you really want to simplify the language, I would suggest that range() should simply return an iterator and the only recommended use be list(range(..)) and for x in range(..) constructs. __length_hint__ can be provided for efficiency of list(range(..)) instead of __length__ and that will eliminate range(<long int>) issues. Note that making range() return an iterator will make it very similar to itertools.count() suggesting that the two should be unified somehow. (With ellipsis becoming a valid argument, would you consider range(...) for count() and range(start, ...) for count(n) too clever? Alternatively, range() for count() and range(n, None) for count(n)?) In any case, turning range into an Iterator is unlikely to be accepted this late in the 3.0 development stage, so I believe making it a Sequence is cleaner and simpler than the status quo. _______________________________________________ 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
