On Sun, Dec 23, 2012 at 12:03 PM, Terry Reedy <tjre...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
