RetroSearch Browse

Fri Nov 12 05:51:15 CET 2004 · https://mail.python.org/pipermail/python-dev/2004-November/049884.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.

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.

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

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

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

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

[Python-Dev] Deprecate PyRange_New()