classification
Title: PyLong_As* methods should not call nb_int.
Type: Stage:
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: later
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson
Priority: normal Keywords:

Created on 2009-12-20 10:31 by mark.dickinson, last changed 2009-12-21 14:45 by mark.dickinson. This issue is now closed.

Messages (4)
msg96670 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-20 10:31
The following C-API functions:

PyLong_AsLongAndOverflow
PyLong_AsUnsignedLongMask
PyLong_AsLongLong
PyLong_AsUnsignedLongLongMask

call nb_int for inputs that don't satisfy PyLong_Check.  They thus accept 
floats, Decimal instances, etc.  They should probably call nb_index 
instead (or perhaps accept only instances of int).

The uses of these functions within the Python source should be checked, to 
see what consequences (if any) this change would have for Python 
semantics; it's possible that some of these consequences would fall under 
the moratorium (PEP 3003).  In any case, this change probably requires a 
1-release deprecation period.
msg96672 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-20 10:37
Since PyLong_AsLong goes through PyLong_AsLongAndOverflow, this change 
would also affect calls to PyLong_AsLong.
msg96678 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-20 14:09
Just as an experiment, I removed the calls to nb_int and ran the test-
suite.  The only test failures were in test_ctypes, test_getargs2, and 
test_math.

The test_math failure was from math.factorial depending on PyLong_AsLong 
to convert floats;  I've fixed this in r76916 (trunk) and r76917 (py3k).

One consequence of not having PyLong_AsLong automatically call nb_int 
would be that math.factorial(decimal.Decimal('-0.53')) is no longer valid.
msg96753 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-21 14:45
It turns out this is intimately bound up with the behaviour of 
PyArg_ParseTuple* for integer format codes.  Since this behaviour can't 
change until Python 3.3 (because of the moratorium), I'm closing this for 
now.
History
Date User Action Args
2009-12-21 14:45:18mark.dickinsonsetstatus: open -> closed
resolution: later
messages: + msg96753
2009-12-20 14:09:52mark.dickinsonsetmessages: + msg96678
2009-12-20 10:37:05mark.dickinsonsetmessages: + msg96672
2009-12-20 10:31:12mark.dickinsoncreate