String formatting using %d doesn't handle well a long value when the object isn't a PyLong itself. 
That is:

py> "%d" % 42L
'42'
py> "%d" % 10000000000000000000000000000000L
'10000000000000000000000000000000'
py> "%d" % 42.0
'42'
py> "%d" % 10000000000000000000000000000000.0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int argument required

Here it was shown with a float object, but any other object with a __long__ or __int__ method returning a PyLong fails (by example, the gmpy package).

Currently PyString_Format, for "%d", checks whether the value *is* a PyLong and processes it, else tries to *convert* it to PyInt (and fails for large values).

The attached patch first checks for a number; if it's a number but not PyInt nor PyLong, tries to convert to int; if it fails, tries to convert to long. The resulting value (either a PyInt or PyLong) is formatted the same way as before. 
If the original object was actually an int or long, it's handled the same way as before.
The test ordering was chosen to only convert to long when necesary.

I have two issues with this patch:

1) I'm not sure it's that bad to need to use '%d' % long(obj) to ensure
conversion to a long integer.

2) If this kind of auto-conversion is deemed useful, then the patch
itself is rather complicated.   I would re-factor so that the same code
is not repeated once in the PyNumber_Check and again in the original
PyLong_Check and else clauses.  Simply check for PyNumber.  Then, if not
already an int or a long, convert to int first and then long if that
creates an error.  Then, excecute the two segments of code for int and
long objects.

I'm positive that this shouldn't happen. There should NOT be any
difference between longs and ints in nowadays Python, so you never
should say to an user to call that long() before the %d.

And, you have some strange behaviours... for example:

>>> "%d" % 9e8
'900000000'
>>> "%d" % 9e9
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int argument required

Why the first is ok and in the second you should have called it through
long()?

Gabriel, could you please take a look to the recommendations that Travis
is doing? Maybe the patch could be simpler... In any case, please
confirm if yes or no, :)

Yes, I can reformulate it. In fact my original version was quite 
different, but the resulting diff was hard to understand so I rewrote 
it trying to keep as much as the original code as possible.
I'll submit a new patch next weekend.

Closed issue 1924 as duplicate of this one, but I'm copying here the
text from David, as it's very explanative:

"""
I ran across this bug in some legacy production code when numbers got high:

>>> '%i' % 2e9
'2000000000'
>>> '%i' % 3e9
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: int argument required

It looks like the float is being automatically converted to an int, but
floats > sys.maxint cause an error.  However,

>>> int(3e9)
3000000000L

So the implicit float-to-int conversion is imperfect; large floats are
not being converted to long ints.

Same error in Python 2.3 through 2.6a0 (as of 2007-12-28).

In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to
convert".  The same error is triggered by int(3e9) though.

While it's arguably not-quite-sane to have code that triggers this
error, the inconsistency is what concerns me.
"""

An updated patch, along the lines given by Travis Oliphant.

I would prefer that %d signal an error 100% of the time if you give it a
float.  It should not accept 42.0.  It is for printing integers.

I am of the opposite side:
%d should accept floats and anything that can be converted to an integer.
It is for printing objects with a decimal format.
(likewise %s is for printing objects that can be converted to a string)

Paul, %d will accept large floats, I need to review Gabriel's patch;
your proposition will break too much code.

Applied in r61040. Thanks you all!

A couple of comments.

1. This bug supersedes issue 1153226
That has good info, including the suggestion that one should
be using the %.f format rather than %d in this case anyway

2. The patch here was actually applied in r61041