New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pow(a, b, c) should not raise TypeError when b is negative and c is provided #65392
Comments
While checking the exceptions used to compare existing behavior while investigating bpo-20539, I noticed a weird behavior in pow() (implemented by long_pow in longobject.c). If a 3rd argument (the modulus) is provided, and the 2nd argument (the exponent) is negative, the function raises TypeError. To my knowledge, TypeError should never be used for this purpose; some functions raise OverflowError for negative values (which violates the documented purpose of OverflowError, but the documents don't match CPython's implementation), others use ValueError (which I believe is appropriate, since it's not a matter of a C type limitation, the function is just logically restricted to the range [0,Largest possible PyLong]. I recommend switching to ValueError, possibly with a deprecation notice before making the switch if people think someone might rely on this behavior. Related: bpo-457066 |
Here's the trivial patch for code and the associated unit test (we were actually testing that it raised TypeError specifically; it now raises ValueError, and the unit test expects ValueError). unit tests passed aside from test_io, but I'm pretty sure that's unrelated; my Linux VM freezes up once in a while, which does nasty things to timing dependent I/O tests. |
As I mentioned on another bug, I filled out and submitted the contributor agreement form electronically earlier this week, it just hasn't propagated yet. I'm fairly sure trained monkeys reading the description of this bug report would produce the exact same patch (s/TypeError/ValueError/ on one line in each of two files) though, so I'll trust you if you say you reimplemented it rather than take the legal risk. :-) |
I was wondering how the TypeError got there in the first place. Diving into the history is instructive: changeset cdfdd5359411 modified the exception message: taniyama:cpython mdickinson$ hg log -r19719 Before that change, the code looked like this: if (x != Py_None) {
PyErr_SetString(PyExc_TypeError, "integer pow() arg "
"3 must not be specified when arg 2 is < 0");
return NULL;
} From that point of view the TypeError makes more sense: it's complaining about the wrong number of arguments rather than the negative value. The current message changes the perspective, and I agree that ValueError makes more sense. Tim: any objections to changing the exception type from TypeError to ValueError for Python 3.5? I'd prefer not to change it for 2.7 or 3.4: there's an (admittedly probably quite low) risk of code breakage, and little real gain to offset that breakage. |
Agreed that there is no need to patch 2.7/3.4; this is a pedantic correctness fix, not a serious bug. |
+1 for ValueError as well. |
Yup, agreed with all: ValueError makes a lot more sense, but the change shouldn't be backported. |
New changeset dc6c2ab7fec2 by Mark Dickinson in branch 'default': |
Patch applied. Thanks, all. |
New changeset a8f3ca72f703 by Benjamin Peterson in branch 'default': |
Benjamin: thanks for the fix. To be clear: Josh Rosenberg's patch had the correct test change. It was the (poorly) trained monkey who made the commit who broke the test. Sorry, all. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: