RetroSearch Browse

Thu Nov 18 06:59:12 CET 2004 · https://mail.python.org/pipermail/python-dev/2004-November/049997.html

> [Raymond Hettinger]
> > A while back, Tim added a comment that PyRange_New() should be
> > deprecated in-part because it is filled with problems and is not
used
> > anywhere in the core.

[Tim]
> And because it's undocumented.  The only place it's even mentioned is
> in the NEWS for 2.3a1:
> 
> - PyRange_New() now raises ValueError if the fourth argument is not 1.
>   This is part of the removal of deprecated features of the xrange
>   object.

[Raymond]
> > Doesn't anyone mind if I mark it in the C-API docs as deprecated so
it
> > can be phased out later?

[Tim]
> +1
> 
> I don't object to *documenting* a PyRange_New() API function, BTW, but
> the current implementation is too broken to fix with less than heroic
> effort.  If PyRange_New() needs to exist in the C API, then it should
> have the same (lo, hi, step) signature as the builtin range(), for
> which we have correct but non-obvious error-checking C code.  The
> funky (start, len, step, reps) signature of the current PyRange_New()
> is much more difficult to check for errors (e.g., detecting C long
> multiplication overflow in portable C is a sub-problem), and the
> current signature is too surprising regardless (because it's so
> different from the builtin range()).

Given that it is undocumented, broken, and recent, would it be over the
top to just remove it from Py2.4?

Raymond

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/049997.html below:

[Python-Dev] Deprecate PyRange_New()