classification
Title: pow(a, b, c) should not raise TypeError when b is negative and c is provided
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.5, Python 3.4, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: josh.r, mark.dickinson, pitrou, python-dev, tim.peters
Priority: normal Keywords: patch

Created on 2014-04-10 00:24 by josh.r, last changed 2014-04-11 19:41 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
pow_typeerror_to_valueerror.patch josh.r, 2014-04-10 03:55 review
Messages (11)
msg215860 - (view) Author: Josh Rosenberg (josh.r) * Date: 2014-04-10 00:24
While checking the exceptions used to compare existing behavior while investigating #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: #457066
msg215864 - (view) Author: Josh Rosenberg (josh.r) * Date: 2014-04-10 03:55
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.
msg215866 - (view) Author: Josh Rosenberg (josh.r) * Date: 2014-04-10 03:57
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. :-)
msg215882 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-04-10 13:49
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
changeset:   19719:cdfdd5359411
branch:      legacy-trunk
user:        Tim Peters <tim.peters@gmail.com>
date:        Wed Sep 05 06:24:58 2001 +0000
summary:     Make the error msgs in our pow() implementations consistent.

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.
msg215884 - (view) Author: Josh Rosenberg (josh.r) * Date: 2014-04-10 14:01
Agreed that there is no need to patch 2.7/3.4; this is a pedantic correctness fix, not a serious bug.
msg215904 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-04-10 19:44
+1 for ValueError as well.
msg215910 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2014-04-10 20:57
Yup, agreed with all:  ValueError makes a lot more sense, but the change shouldn't be backported.
msg215942 - (view) Author: Roundup Robot (python-dev) Date: 2014-04-11 18:35
New changeset dc6c2ab7fec2 by Mark Dickinson in branch 'default':
Issue #21193: Make (e.g.,) pow(2, -3, 5) raise ValueError rather than TypeError.  Patch by Josh Rosenberg.
http://hg.python.org/cpython/rev/dc6c2ab7fec2
msg215943 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-04-11 18:36
Patch applied. Thanks, all.
msg215949 - (view) Author: Roundup Robot (python-dev) Date: 2014-04-11 19:38
New changeset a8f3ca72f703 by Benjamin Peterson in branch 'default':
test the change of #21193 correctly
http://hg.python.org/cpython/rev/a8f3ca72f703
msg215951 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-04-11 19:41
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.
History
Date User Action Args
2014-04-11 19:41:20mark.dickinsonsetmessages: + msg215951
2014-04-11 19:38:09python-devsetmessages: + msg215949
2014-04-11 18:36:53mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg215943

stage: resolved
2014-04-11 18:35:14python-devsetnosy: + python-dev
messages: + msg215942
2014-04-10 20:57:41tim.peterssetmessages: + msg215910
2014-04-10 19:44:26pitrousetnosy: + pitrou
messages: + msg215904
2014-04-10 14:01:17josh.rsetmessages: + msg215884
2014-04-10 13:50:20mark.dickinsonsetassignee: mark.dickinson
2014-04-10 13:49:29mark.dickinsonsetnosy: + tim.peters
messages: + msg215882
2014-04-10 03:57:34josh.rsetmessages: + msg215866
2014-04-10 03:55:14josh.rsetfiles: + pow_typeerror_to_valueerror.patch
keywords: + patch
messages: + msg215864
2014-04-10 03:28:49ned.deilysetnosy: + mark.dickinson

versions: - Python 3.1, Python 3.2, Python 3.3
2014-04-10 00:24:57josh.rcreate