On Tue, Sep 27, 2011 at 1:12 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote: > On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman <et...@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@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@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com