pow(a, b, c) should not raise TypeError when b is negative and c is provided

[MojoVampire]

BPO	21193
Nosy	@tim-one, @mdickinson, @pitrou, @MojoVampire
Files	pow_typeerror_to_valueerror.patch

^{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:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2014-04-11.18:36:53.153>
created_at = <Date 2014-04-10.00:24:57.452>
labels = ['interpreter-core', 'type-bug']
title = 'pow(a, b, c) should not raise TypeError when b is negative and c is provided'
updated_at = <Date 2014-04-11.19:41:20.224>
user = 'https://github.com/MojoVampire'

bugs.python.org fields:

activity = <Date 2014-04-11.19:41:20.224>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2014-04-11.18:36:53.153>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2014-04-10.00:24:57.452>
creator = 'josh.r'
dependencies = []
files = ['34780']
hgrepos = []
issue_num = 21193
keywords = ['patch']
message_count = 11.0
messages = ['215860', '215864', '215866', '215882', '215884', '215904', '215910', '215942', '215943', '215949', '215951']
nosy_count = 5.0
nosy_names = ['tim.peters', 'mark.dickinson', 'pitrou', 'python-dev', 'josh.r']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21193'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[MojoVampire]

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

[MojoVampire]

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.

[MojoVampire]

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. :-)

[mdickinson]

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.

[MojoVampire]

Agreed that there is no need to patch 2.7/3.4; this is a pedantic correctness fix, not a serious bug.

[pitrou]

+1 for ValueError as well.

[tim-one]

Yup, agreed with all: ValueError makes a lot more sense, but the change shouldn't be backported.

[python-dev]

New changeset dc6c2ab7fec2 by Mark Dickinson in branch 'default':
Issue bpo-21193: Make (e.g.,) pow(2, -3, 5) raise ValueError rather than TypeError. Patch by Josh Rosenberg.
http://hg.python.org/cpython/rev/dc6c2ab7fec2

[mdickinson]

Patch applied. Thanks, all.

[python-dev]

New changeset a8f3ca72f703 by Benjamin Peterson in branch 'default':
test the change of bpo-21193 correctly
http://hg.python.org/cpython/rev/a8f3ca72f703

[mdickinson]

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.