Currently int() ignores base keyword argument if first string argument omitted. Such usage is no other than bug. The proposed patch raises TypeError in such case.

See also discussion at Python-Dev: http://comments.gmane.org/gmane.comp.python.cvs/92290 .

In additional some int creation tests backported to old Python versions.

Patches updated to address Cris's  comments on Rietveld (thank you, Cris, for 
review). In additional new tests added. I think merging test_int and test_long 
is hard task and should be done in separated issue. Instead I have merged and 
simplified some test to make synchronization simpler.

Two new possible bugs were found during working on these tests (issue16772 and 
issue16773).

This is good work.  Thanks.

> I think merging test_int and test_long is hard task and should be done in separated issue.

I meant "share" rather than "merge."  For the tests you're adding, isn't it simply a matter of putting the test cases into a separate mixin or TestCase class in a different module, and then importing and subclassing that (and setting the type to use as an attribute of the subclass)?  Or am I missing something?

Having just looked added something to test_int as part of issue16772... There appears to be an explicit test _for_ this strange behavior in there:

http://hg.python.org/cpython/file/60f7197f991f/Lib/test/test_int.py#l233

test_base_arg_with_no_x_arg

I have no idea why this exists or was desired.

See this thread:

http://mail.python.org/pipermail/python-dev/2012-December/123283.html

Sharing only those tests is not enough. We must revise all tests and extract common code to the separated class. I think this is too large change and unrelated to this issue. I will open a new issue for int tests enhancement and refactoring.

It's enough not to make the problem worse, which is why I suggested it and what I wanted to avoid.  If you copy-paste the tests you're adding now, it worsens the problem and makes it that much more tedious to fix later on (and to maintain in the meantime).

Why must the code sharing be all or nothing?  Elsewhere we phase in improvements incrementally.  Even with the particular refactoring you're suggesting for the future, I'm not sure we'd want to do it all in one patch.

If you begin the process now and add appropriate comments and TODO's pointing the way, at least the next person will know how to take the next steps.

Here is a patches which contains only minimal set of required changes. Other 
unrelated changes will be done in issue16784.

Let's eat an elephant piece by piece. Only one issue per patch.

Yes, it is a better approach.  At first glance, the patches look okay to me.

When this patch is updated because of the commit for issue 16790, in 3.x can the edited test cases be moved to the top of the test class per the following comment (as appropriate)?

http://bugs.python.org/issue16790#msg178282

As stated there, this will make synching tests between 2.7 and 3.x easier.  We can do the others in 3.x whenever more are added to the 2.7 common tests.

I don't think a backport is appropriate for this kind of change.

New changeset c0266ba8e4c6 by Serhiy Storchaka in branch '2.7':
Issue #16761: Raise TypeError when int() or long() called with base argument only.
http://hg.python.org/cpython/rev/c0266ba8e4c6

New changeset e4ea38a92c4d by Serhiy Storchaka in branch '3.2':
Issue #16761: Raise TypeError when int() called with base argument only.
http://hg.python.org/cpython/rev/e4ea38a92c4d

New changeset 157ff02bcc16 by Serhiy Storchaka in branch '3.3':
Issue #16761: Raise TypeError when int() called with base argument only.
http://hg.python.org/cpython/rev/157ff02bcc16

New changeset 1b2134a78c17 by Serhiy Storchaka in branch 'default':
Issue #16761: Raise TypeError when int() called with base argument only.
http://hg.python.org/cpython/rev/1b2134a78c17

> When this patch is updated because of the commit for issue 16790, in 3.x can the edited test cases be moved to the top of the test class per the following comment (as appropriate)?

I will do this in issue16784. In any case I am going to move a large part of test_basic/test_long to IntLongCommonTests and then those test will be above test_keyword_args.

Why did you backport this change after being advised not to do it?

Sorry, I have not noticed your advice before I did commit (it took me a lot of time). Should I now revert my changes to 2.7, 3.2 and 3.3?

If PyPy gets away with a different behaviour, there's probably nobody relying on it, so I'd say the backports are safe.

> Should I now revert my changes to 2.7, 3.2 and 3.3?

Once committed, I would say leave it in as long as you're confident that no currently working code will break as a result.  In general, be very conservative about backporting any behavioral change.