What could generate the following behavior ?
>>> print str(msg)
my message
>>> print unicode(msg)
my message
But:
>>> print '%s' % msg
another message
More info:
- my
msg
object is inherited fromunicode
. - the methods
__str__
/__unicode__
/__repr__
methods were overridden to return the string'my message'
. - the
msg
object was initialised with the string'another message'
. - this is running on python 2.5
- the variable
msg
was not changed between the tests - this is actually real doctest that is really giving these results.
I would like an solution that matches this doctest, with minimal fuss (especially around the actual inheritance):
>>> print '%s' % msg
my message
Thanks for all suggestions.
I don't feel this will help more, but for curious readers (and adventurous pythonist), here's the implementation of the object:
class Message(zope.i18nmessageid.Message):
def __repr__(self):
return repr(zope.i18n.interpolate(self.default, self.mapping))
def __str__(self):
return zope.i18n.interpolate(self.default, self.mapping)
def __unicode__(self):
return zope.i18n.interpolate(self.default, self.mapping)
This is how we crea开发者_如何学JAVAte the object msg:
>>> msg = Message('another message', 'mydomain', default='my message')
Zope packages version and code used are:
- zope.i18n-3.4.0 (interpolation() method code )
- zope.i18nmessageid-3.4.3 (Message class code)
EDIT INFO:
- added/updated the names of the methods that were overriden
- added some more info (python version, and minor info)
- updated some wrong info (the class of `msg` is based on `unicode` class and not `basestring`)
- added the actual implementation of the class used
Update 2: Please find the original answer, including a simple example of a class exhibiting the behaviour described by the OP, below the horizontal bar. As for what I was able to surmise in the course of my inquiry into Python's sources (v. 2.6.4):
The file Include/unicodeobject.h
contains the following to lines (nos. 436-7 in my (somewhat old) checkout):
#define PyUnicode_AS_UNICODE(op) \
(((PyUnicodeObject *)(op))->str)
This is used all over the place in the formatting code, which, as far as I can tell, means that during string formatting, any object which inherits from unicode
will be reached into so that its unicode string buffer may be used directly, without calling any Python methods. Which is good as far as performance is concerned, I'm sure (and very much in line with Juergen's conjecture in a comment on this answer).
For the OP's question, this probably means that making things work the way the OP would like them to may only be possible if something like Anurag Uniyal's wrapper class idea is acceptable for this particular use case. If it isn't, the only thing which comes to my mind now is to wrap objects of this class in str
/ unicode
wherever their being interpolated into a string... ugh. (I sincerely hope I'm just missing a cleaner solution which someone will point out in a minute!)
(Update: This was posted about a minute before the OP included the code of his class, but I'm leaving it here anyway (1) for the conjecture / initial attempt at an explanation below the code, (2) for a simple example of how to produce this behaviour (Anurag Uniyal has since provided another one calling unicode
's constructor directly, as opposed to via super
), (3) in hope of later being able to edit in something to help the OP in obtaining the desired behaviour.)
Here's an example of a class which actually works like what the OP describes (Python 2.6.4, it does produce a deprecation warning -- /usr/bin/ipython:3: DeprecationWarning: object.__init__() takes no parameters
):
class Foo(unicode):
def __init__(self, msg):
super(unicode, self).__init__(msg)
def __str__(self): return 'str msg'
def __repr__(self): return 'repr msg'
def __unicode__(self): return u'unicode msg'
A couple of interactions in IPython:
In [12]: print(Foo("asdf"))
asdf
In [13]: str(Foo("asdf"))
Out[13]: 'str msg'
In [14]: print str(Foo("asdf"))
-------> print(str(Foo("asdf")))
str msg
In [15]: print(str(Foo("asdf")))
str msg
In [16]: print('%s' % Foo("asdf"))
asdf
Apparently string interpolation treats this object as an instance of unicode
(directly calling the unicode
implementation of __str__
), whereas the other functions treat it as an instance of Foo
. How this happens internally and why it works like this and whether it's a bug or a feature, I really don't know.
As for how to fix the OP's object... Well, how would I know without seeing its code??? Give me the code and I promise to think about it! Ok, I'm thinking about it... No ideas so far.
So problem is class like to something below behaves weirdly
class Msg(unicode):
def __init__(self, s):
unicode.__init__(self, s)
__unicode__ = __repr__ = __str__ = lambda self: "my message"
msg = Msg("another message")
print str(msg)
print unicode(msg)
print "%s"%msg
this prints
my message
my message
another message
I am not sure why this happens or how to fix it, but a very crude attempt by wrapping Msg, but not sure it will help in OP's problem
class MsgX(object):
def __init__(self, s):
self._msg = Msg(s)
__unicode__ = __repr__ = __str__ = lambda self: repr(self._msg)
msg = MsgX("another message")
print str(msg)
print unicode(msg)
print "%s"%msg
output:
my message
my message
my message
I think your problem is that you are trying to extend a built-in. Magic __
methods don't get called for builtins. I think you will have to do some kind of wrap-and-delegate, like this (untested) (maybe Anurag beat me to the punch):
class Message(object):
def __init__(self, strvalue, domain, default='my message'):
self.msg = zope.i18nmessageid.Message(strvalue,domain,default)
def __getattr__(self,attr):
return getattr(self.msg,attr)
def __repr__(self):
return repr(zope.i18n.interpolate(self.msg.default, self.msg.mapping))
def __str__(self):
return zope.i18n.interpolate(self.msg.default, self.msg.mapping)
def __unicode__(self):
return zope.i18n.interpolate(self.msg.default, self.msg.mapping)
Update 1 - it seems that __
methods do get called for subclasses of builtins
>>> class Z(int):
... def __add__(self,other): return self*other
... def __str__(self): return "***"
...
>>> a = Z(100)
>>> a + 2
200
>>> a
100
>>> str(a)
'***'
>>> "%s" % a
'***'
So there is definitely some inconsistency going on...
精彩评论