[Python-Dev] [Python-checkins] cpython (3.3): Issue #16045: add more unit tests for built-in int()

[Chris Jerdonek]

On Sun, Dec 23, 2012 at 12:03 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>
>> +    # For example, PyPy 1.9.0 raised TypeError for these cases because it
>> +    # expects x to be a string if base is given.
>> +    @support.cpython_only
>> +    def test_base_arg_with_no_x_arg(self):
>> +        self.assertEquals(int(base=6), 0)
>> +        # Even invalid bases don't raise an exception.
>> +        self.assertEquals(int(base=1), 0)
>> +        self.assertEquals(int(base=1000), 0)
>> +        self.assertEquals(int(base='foo'), 0)
>
>
> I think the above behavior is buggy and should be changed rather than frozen
> into CPython with a test. According to the docs, PyPy does it right.

I support further discussion here.  (I did draft the patch, but it was
a first version.  I did not commit the patch.)

> The current online doc gives the signature as
> int(x=0)
> int(x, base=10) <<where x is s string>>
>
> The 3.3.0 docstring says
> "When converting a string, use the optional base.  It is an error to supply
> a base when converting a non-string."

One way to partially explain CPython's behavior is that when base is
provided, the function behaves as if x defaults to '0' rather than 0.
This is similar to the behavior of str(), which defaults to b'' when
encoding or errors is provided, but otherwise defaults to '':

http://docs.python.org/dev/library/stdtypes.html#str

> Certainly, accepting any object as a base, violating "The allowed values are
> 0 and 2-36." just because giving a base is itself invalid is crazy.

For further background (and you can see this is the 2.7 commit),
int(base='foo') did raise TypeError in 2.7, but this particular case
was relaxed in Python 3.

--Chris