homepage

With file xx.py:
class Foo(object):
 def __init__(self, x):
 self.x = x
 def __long__(self):
 return long(self.x)
 def __float__(self):
 return float(self.x)
y = Foo(22)
print '%d' % y
print '%d' % y
Interactive mode:
$ python -V
Python 2.6.7
$ python -i xx.py
22
22
>>>
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
It alternates between printing '22' and print a TypeError message. Expected it to be consistent.
Also, the first carraige-return (with no input) results in an error message. Did not expect an error message. In fact, typing pretty much anything (e.g. an undefined variable or raise(Exception())) results in the same error message.
On Mac OS X Darwin Kernel Version 10.8.0
Python 2.6.7 (r267:88850, Jul 6 2011, 13:57:37) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Thanks.

I think this must be a change between 2.5 and 2.6.
In 2.5.1 non-debug (Linux) I consistently see:
>>> print '%d' % y
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: int argument required
In 2.6.5 (Windows via activestate) I see the alternating errors reported here.
In 2.7.2+ debug (Linux) I consistently see:
>>> print '%d' % y
22
XXX undetected error
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not 'Foo'
[38749 refs]
Note the "XXX undetected error".
In 2.7.2+ non-debug (Linux), I get the alternating errors reported here.
I don't think anything will be done about the problem in 2.6. For 2.7, the "XXX undetected error" should be investigated, and will likely point to the problem.

With Darwin 10.8.0 x86_64, I confirm the behavior described in first message.
$ python2.7 -V
Python 2.7.2
$ python2.7 -i xx.py
22
22
>>> 
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>>

A debug build displays "XXX undetected error". An error condition was not correctly cleared, see attached patch.

New patch with a unit test.

Sorry I found that u'%d' is equally affected, here is a new version.

I don't think you're going to want those print statements in a test. You could just evaluate '%d' % y.

Unfortunately without the "print" the test does not fail.

With an unpatched 2.7, this fails for me:
diff --git a/Lib/test/test_format.py b/Lib/test/test_format.py
--- a/Lib/test/test_format.py
+++ b/Lib/test/test_format.py
@@ -289,6 +289,17 @@
 else:
 raise TestFailed, '"%*d"%(maxsize, -127) should fail'
 
+ def test_issue13410(self):
+ class Foo(object):
+ def __init__(self, x):
+ self.x = x
+ def __long__(self):
+ return long(self.x)
+ def __float__(self):
+ return float(self.x)
+ '%d' % Foo(22)
+
 def test_main():
 test_support.run_unittest(FormatTest)
 
$ ./python Lib/test/regrtest.py test_format
test_format
test test_format crashed -- <type 'exceptions.TypeError'>: int() argument must be a string or a number, not 'Foo'
1 test failed:
 test_format

$ ./python Lib/test/regrtest.py test_format
shows the error, but
$ ./python Lib/test/regrtest.py -v test_format
does not fail!
The "print" is needed, can something else have the same effect?

Interesting! Same here.
Using eval() fails with or without -v:
--- a/Lib/test/test_format.py
+++ b/Lib/test/test_format.py
@@ -289,6 +289,18 @@
 else:
 raise TestFailed, '"%*d"%(maxsize, -127) should fail'
 
+ def test_issue13410(self):
+ class Foo(object):
+ def __init__(self, x):
+ self.x = x
+ def __long__(self):
+ return long(self.x)
+ def __float__(self):
+ return float(self.x)
+ eval(u'%d' % Foo(22))
+ eval('%d' % Foo(22))
+
+
 def test_main():
 test_support.run_unittest(FormatTest)
 
I've put both '%d' and u'%d' here, but it also fails with just one of them.

Fwiw, a class with methods __long__ and __float__ but no method __int__ behaves strangely in many other places; the canonical example is that calling "int(Foo(42))" will not work. In light of this, does it make sense for "'%d' % Foo(42)" to work? Shouldn't the fix instead be to cleanly raise the TypeError instead?

The issue for str was fixed in issue15516. The issue for unicode is not fixed yet.

New changeset a06654ca0134 by Serhiy Storchaka in branch '2.7':
Issue #13410: Fixed a bug in PyUnicode_Format where it failed to properly
https://hg.python.org/cpython/rev/a06654ca0134