[Python-Dev] range objects in 3.x

[Guido van Rossum]

On Tue, Sep 27, 2011 at 1:12 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> 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.

This sound like a rather over-designed API.

> 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
>>
> _______________________________________________
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)