[Python-Dev] range objects in 3.x

[Eric Snow]

On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Good points.  So how about:
>
> some_name_here(start, stop, *, step=None, count=None)
>
> ?  I personally would use the step value far more often than the count
> value.

Let's call it xrange() or maybe range_ex().  <wink>  But seriously,
here's an approach that extends the generic replacement idea a bit.

I like the idea of the "some_name_here" function as a builtin in
conjunction with Alexander's idea of a generic function, a la len() or
repr().  Like those other builtin generic functions, it would leverage
special methods (whether new or existing) to use the "range protocol"
of objects.

The builtin would either replace range() (and assume its name) or be a
new builtin with a parallel name to range().  Either way, it would
return an object of the new/refactored range type, which would reflect
the above signature.

If the new builtin were to rely on a new range-related protocol (i.e.
if it were needed), that protocol could distinguish support for
stepping from support for counting.  Then floats could simply not
support the stepping portion.

And the fate of range()?

As far as the existing builtin range() goes, either we would leave it
alone, we would make range() a wrapper function around a new range
type, or the new range type would completely replace the old.  If we
were to leave it alone, the new builtin would have a name that
parallels the old name.  Then we wouldn't have to worry about backward
compatibility for performance, type, or signature.

Going the wrapper function route would preserve backward compatibility
for the function signature, but  isinstance(obj, range) wouldn't work
anymore.  Whether leaving range() alone or making it a wrapper, we
could replace it with the new builtin in Python 4, if it made sense
(like happened with xrange).

If we entirely replaced the current range() with the new (more
generic) range type, the biggest concern is maintaining backward
compatibility with the function signature, in both Python and the
C-API.  That would be tricky since the above signature seems
incompatible with the current one.

-eric

>
> ~Ethan~
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com
>