[Python-Dev] range objects in 3.x (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Tue Sep 27 22:12:52 CEST 2011

On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

Good points.  So how about:

somenamehere(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(). 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

More information about the Python-Dev mailing list