You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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=Noneclosed_at=<Date2009-12-21.14:45:18.005>created_at=<Date2009-12-20.10:31:12.790>labels= ['interpreter-core']
title='PyLong_As* methods should not call nb_int.'updated_at=<Date2009-12-21.14:45:18.003>user='https://github.com/mdickinson'
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.
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.
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.
Activity
mdickinson commentedon Dec 20, 2009
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.
mdickinson commentedon Dec 20, 2009
Since PyLong_AsLong goes through PyLong_AsLongAndOverflow, this change
would also affect calls to PyLong_AsLong.
mdickinson commentedon Dec 20, 2009
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.
mdickinson commentedon Dec 21, 2009
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.