Currently all but one of the integer format codes for getargs.c raise TypeError when passed a float.  The 'L' code produces a warning rather than raising an error.

This was deliberate at the time, because all except the 'L' code already raised a DeprecationWarning in Python 3.1, and were converted to raise TypeError for 3.2.  Since the 'L' code didn't raise a warning for float inputs in 3.1, directly raising a TypeError in 3.2 seemed a bit abrupt.

However, I'd like to revisit this decision, and make the 'L' code raise a TypeError in 3.2.  Note that

(1) The 'L' code represents the Py_LONG_LONG type, and isn't used very much;  I think the risk of unexpected breakage from this change is fairly small.

(2) One of the places that the 'L' code *is* used is when parsing strange C types (like off_t) that are matched with either size_t, long or long long at configure + build time.  So one platform might end up parsing off_t types with the 'n' code, while another parses them with the 'L' code.  It would be desirable for both platforms to have the same behaviour when passed a float.

Any objections to making this change?

See also issue 5080.

> One of the places that the 'L' code *is* used is when parsing
> strange C types (like off_t)

It has unexepected consequences. Example:

   >>> x=open("x", "w")
   >>> x.seek(0.0)
   0.0
   >>> x.seek(-0.0)
   -0.0
   >>> x.seek(0.1)
   0.1
   >>> x.tell()
   0

I think that we should just raise an error in Python 3.2 because I consider this as a bug. It remembers me another bug related to file and float: http://bugs.python.org/issue5080#msg92400

Here's a patch.  Victor, are you interested in reviewing?

Le mercredi 09 juin 2010 14:24:01, vous avez écrit :
> Here's a patch.  Victor, are you interested in reviewing?

I ran the whole test suite: there is no error. The patch is ok, please commit 
it in Python 3.2.

Committed, r81873.  Thanks for reviewing, Victor.