Deprecate PyRange_New()
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. Doesn't anyone mind if I mark it in the C-API docs as deprecated so it can be phased out later? Raymond Hettinger
On Wed, Nov 10, 2004, Raymond Hettinger wrote:
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.
Doesn't anyone mind if I mark it in the C-API docs as deprecated so it can be phased out later?
+1 +1 on emitting a compiler warning in 2.5 (a bit late for 2.4, I think). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ WiFi is the SCSI of the 21st Century -- there are fundamental technical reasons for sacrificing a goat. (with no apologies to John Woods)
[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()).
[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
Given that it is undocumented, broken, and recent, would it be over the top to just remove it from Py2.4?
Given that 2.4 is (or nearly is) a release candidate, do you even need to ask that? :)
Yes ;-) The code is buggy and undocumented. Fixing bugs and adding documentation are appropriate after the beta and before the release candidate. However, in this case, a complete bugfix would also entail a change in the signature. And since the function is unnecessary, removing it entirely is a safer fix. Leaving it in only increases the risk that someone will find it and link to it. OTOH, I don't care enough about this one to push it. Raymond
participants (5)
-
Aahz -
Barry Warsaw -
Raymond Hettinger -
Raymond Hettinger -
Tim Peters