CPython crash with '%o'
This is my first post, so here's a quick intro: I've recently joined the IronPython team at Microsoft, after about 6 years as a developer on the the .NET runtime (CLR).
I'm currently trying to make IronPython match CPython's behavior regarding some % format string to a level of detail not documented by the spec. (http://docs.python.org/lib/typesseq-strings.html)
While exploring to determine what CPython's behavior is, I'm hitting a SystemError in CPython.
Given the following snippet:
class c(long):
def __oct__(self):
return '100'
x=c(5)
oct(x) # expected to print 100
'%o' % x # expected to use print '5'
It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ and print 5.
However, I'm hitting an SystemError in CPython with this snippet:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] onwin32
Type "help", "copyright", "credits" or "license" for more information.
>>> class c(long):
... def __oct__(self):
... return '100'
...
>>> x=c(5)
>>> oct(x) # expected to print 100
'100'
>>> '%o' % x # expected to use print '5'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to internal function
Note that if c derives from 'int' instead of 'long', everything works as expected.
1. Can somebody confirm that '%o' should not use __oct__ and that is uses __int__ instead, and that the correct output from ('%o' % x) is indeed 5?
2. Should I file a bug for the SystemError exception?
Thanks,
Mike
http://blogs.msdn.com/jmstall
Yes, and yes. There may be time still to fix the SystemError in 2.5.2! On Nov 14, 2007 11:16 AM, Mike Stall <jmstall@exchange.microsoft.com> wrote:
This is my first post, so here's a quick intro: I've recently joined the IronPython team at Microsoft, after about 6 years as a developer on the the .NET runtime (CLR).
I'm currently trying to make IronPython match CPython's behavior regarding some % format string to a level of detail not documented by the spec. (http://docs.python.org/lib/typesseq-strings.html)
While exploring to determine what CPython's behavior is, I'm hitting a SystemError in CPython.
Given the following snippet:
class c(long): def __oct__(self): return '100'
x=c(5) oct(x) # expected to print 100 '%o' % x # expected to use print '5'
It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ and print 5.
However, I'm hitting an SystemError in CPython with this snippet:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] onwin32 Type "help", "copyright", "credits" or "license" for more information.
class c(long): ... def __oct__(self): ... return '100' ... x=c(5) oct(x) # expected to print 100 '100' '%o' % x # expected to use print '5' Traceback (most recent call last): File "<stdin>", line 1, in <module> SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to internal function
Note that if c derives from 'int' instead of 'long', everything works as expected.
1. Can somebody confirm that '%o' should not use __oct__ and that is uses __int__ instead, and that the correct output from ('%o' % x) is indeed 5? 2. Should I file a bug for the SystemError exception?
Thanks, Mike http://blogs.msdn.com/jmstall
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
I take back the first "Yes" answer. Alas, the % operator is a mess, especially for %d/%o/%x. For subclassed longs, it *is* attempting to call the overridden __oct__, and this is causing the SystemError. It looks like this code wasn't really revisited when subclassing int and long was introduced. :-( For subclassed ints, it never looks at the overridden __oct__. For objects that are neither, it attempts to convert them to ints using __int__ first. The trend in 3.0 is to completely kill __oct__ specialization and rely only on __int__ instead. So maybe I should retract my retraction and claim that '%o' % c(5) should indeed return '5'. The bug stands though. There's a relatively simple fix. --Guido On Nov 14, 2007 11:41 AM, Guido van Rossum <guido@python.org> wrote:
Yes, and yes. There may be time still to fix the SystemError in 2.5.2!
On Nov 14, 2007 11:16 AM, Mike Stall <jmstall@exchange.microsoft.com> wrote:
This is my first post, so here's a quick intro: I've recently joined the IronPython team at Microsoft, after about 6 years as a developer on the the .NET runtime (CLR).
I'm currently trying to make IronPython match CPython's behavior regarding some % format string to a level of detail not documented by the spec. (http://docs.python.org/lib/typesseq-strings.html)
While exploring to determine what CPython's behavior is, I'm hitting a SystemError in CPython.
Given the following snippet:
class c(long): def __oct__(self): return '100'
x=c(5) oct(x) # expected to print 100 '%o' % x # expected to use print '5'
It looks like in CPython, '%o' uses __int__ and so it should ignore __oct__ and print 5.
However, I'm hitting an SystemError in CPython with this snippet:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] onwin32 Type "help", "copyright", "credits" or "license" for more information.
class c(long): ... def __oct__(self): ... return '100' ... x=c(5) oct(x) # expected to print 100 '100' '%o' % x # expected to use print '5' Traceback (most recent call last): File "<stdin>", line 1, in <module> SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to internal function
Note that if c derives from 'int' instead of 'long', everything works as expected.
1. Can somebody confirm that '%o' should not use __oct__ and that is uses __int__ instead, and that the correct output from ('%o' % x) is indeed 5? 2. Should I file a bug for the SystemError exception?
Thanks, Mike http://blogs.msdn.com/jmstall
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Mike Stall wrote:
Traceback (most recent call last): File "<stdin>", line 1, in <module> SystemError: \loewis\25\python\Objects\stringobject.c:4236: bad argument to internal function Note that if c derives from 'int' instead of 'long', everything works as expected.
I'm able to reproduce the error with Python 2.5.1 and 2.5 svn on Linux. It also happens when I overwrite __hex__ and do "%x" % c(5) for subclasses of long but not for subclasses from int. class c(long): def __hex__(self): return "100" def __oct__(self): return "100"
x = c(5) hex(x) '100' oct(x) '100' "%o" % x Traceback (most recent call last): File "<stdin>", line 1, in <module> SystemError: Objects/stringobject.c:4269: bad argument to internal function "%x" % x Traceback (most recent call last): File "<stdin>", line 1, in <module> SystemError: Objects/stringobject.c:4269: bad argument to internal function
Objects/stringobject.c:_PyString_FormatLong(...) ... /* To modify the string in-place, there can only be one reference. */ if (result->ob_refcnt != 1) { PyErr_BadInternalCall(); return NULL; } ... Christian
participants (3)
-
Christian Heimes -
Guido van Rossum -
Mike Stall