The built-in function int() does not seem to have any basic unit tests (e.g. in test_builtin).  It would be good to add some.

Some cases (including edge cases) for possible inclusion:

int()
int(base='foo')  # no exception; returns 0
int(x=5)
int(x=5, base=10)  # raises TypeError
int(5.8)  # test truncation towards zero
int(-5.8)  # ditto
int('5.8')  # raises ValueError

Both positional and keyword argument combinations should be tested.

Well, have you looked at test_int?

Thanks for the pointer.  That should do it. :)  Searching for "test_int(" completely missed test_int.py.

[Reopening] Actually, there may still be value in this.  Not all of the edge cases I mentioned are covered (e.g. calling using keyword arguments).

We should also add a code-comment pointer in test_builtin to test_int (where test_int() would be located).

Before adding tests (and possibly documentation) for edge cases like

> int(base='foo')  # no exception; returns 0

I'd take a look at what other implementations do.  If they do something different we might still decide to keep the tests and mark them as cpython-specific, but I would refrain to document them.

Good thought.  Here is one data point:

$ pypy
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:11)
[PyPy 1.9.0] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> int()
0
>>>> int(x='10', base=8)
8
>>>> int(x=5, base=10) 
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: int() can't convert non-string with explicit base
>>>> int(base=6)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: int() can't convert non-string with explicit base
>>>> int(base='foo')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: expected integer, got str object

So it looks like "no x with given base" is where behavior differs.

From http://bugs.python.org/review/16036/ for issue 16036:

> Somewhere should be exposed that x must be str, bytes, bytearray or a subclass.

We can add tests for this, too (if not already there).

Attaching first version of patch.  Interestingly, not all of these pass when I tried applying to 2.7.  For example,

>>> int(base='foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

So at least one modification will be needed there.

Adding patch modified for 2.7.  Here are the differences I found from 3.3.  Unlike 3.3--

(1) 2.7 does not accept bytearrays for x (though it accepts str/bytes).
(2) 2.7 raises a TypeError if passed a string base without providing x.

Is it acceptable to add tests like this to the 2.7 branch?

This information also helps in preparing the 2.7 documentation patch for issue 16036 and ensuring that it is correct.

looks good to me

New changeset c502a2dc0345 by Andrew Svetlov in branch '2.7':
Issue #16045: add more unit tests for built-in int()
http://hg.python.org/cpython/rev/c502a2dc0345

New changeset a90d7003966e by Andrew Svetlov in branch '3.3':
Issue #16045: add more unit tests for built-in int()
http://hg.python.org/cpython/rev/a90d7003966e

New changeset ec7146b18274 by Andrew Svetlov in branch 'default':
Issue #16045: add more unit tests for built-in int()
http://hg.python.org/cpython/rev/ec7146b18274

Committed. Thanks.

New changeset eb1734e579f7 by Chris Jerdonek in branch '2.7':
Issue #16790: add some of the recent issue #16045 int tests to test_long.
http://hg.python.org/cpython/rev/eb1734e579f7