Disallow float arguments where an integer is expected in Python 2.7.
In Python 2.7, PyArg_ParseTuple and friends currently accept a float argument where an integer is expected, but produce a DeprecationWarning in this case. This can be seen in various places in Python proper:
itertools.combinations(range(5), 2.0) __main__:1: DeprecationWarning: integer argument expected, got float
Are there any objections to turning this DeprecationWarning into a TypeError for Python 2.7? The behaviour has been deprecated since Python 2.3, it's gone in 3.x, and having it produce an error in 2.7 might slightly reduce the number of surprises involved in porting from 2.x to 3.x. There's a patch at http://bugs.python.org/issue5080 There's one fly in the ointment: the deprecation warning is produced for all integer codes except for one---the 'L' code. The patch adds a deprecation warning for this code. Mark
On Mon, Dec 21, 2009 at 07:02, Mark Dickinson
In Python 2.7, PyArg_ParseTuple and friends currently accept a float argument where an integer is expected, but produce a DeprecationWarning in this case. This can be seen in various places in Python proper:
itertools.combinations(range(5), 2.0) __main__:1: DeprecationWarning: integer argument expected, got float
Are there any objections to turning this DeprecationWarning into a TypeError for Python 2.7? The behaviour has been deprecated since Python 2.3, it's gone in 3.x, and having it produce an error in 2.7 might slightly reduce the number of surprises involved in porting from 2.x to 3.x. There's a patch at http://bugs.python.org/issue5080
I'm +0 -Brett
On Mon, Dec 21, 2009 at 7:02 AM, Mark Dickinson
In Python 2.7, PyArg_ParseTuple and friends currently accept a float argument where an integer is expected, but produce a DeprecationWarning in this case. This can be seen in various places in Python proper:
itertools.combinations(range(5), 2.0) __main__:1: DeprecationWarning: integer argument expected, got float
Are there any objections to turning this DeprecationWarning into a TypeError for Python 2.7? The behaviour has been deprecated since Python 2.3, it's gone in 3.x, and having it produce an error in 2.7 might slightly reduce the number of surprises involved in porting from 2.x to 3.x. There's a patch at http://bugs.python.org/issue5080
There's one fly in the ointment: the deprecation warning is produced for all integer codes except for one---the 'L' code. The patch adds a deprecation warning for this code.
Mark
+0.5 from me assuming that warning has been present by default in python 2.5 and 2.6. (the fly prevents me from giving it a full +1 as it effectively means some APIs have never issued the warning at all). No hard feelings if the 'L' forces us to back off and not do this. At least its fixed in 3.x.
participants (3)
-
Brett Cannon -
Gregory P. Smith -
Mark Dickinson