Message12408

Author jeff.allen
Recipients jeff.allen, psykiatris
Date 2019-03-28.09:23:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553764982.76.0.947911697025.issue2649@roundup.psfhosted.org>
In-reply-to
Content
I claim to have fixed this (for now) at: https://hg.python.org/jython/rev/d24e20f4fc1e

Working on this I'm reminded that the way we manage __str__ and __repr__ (and __unicode__ and bytes/String confusion generally) is still quite fragile in Jython. Although Patrick's solutions in this area of Jython didn't all seem quite right, drawing attention to the divergence and its root cause is a significant contribution (thanks).

In CPython there is a PyObject_Repr (https://github.com/python/cpython/blob/2.7/Objects/object.c#L364) that deals with __repr__ implementations and always returns a str. I think this is what we needed here (and other places) and as such I'm not wholly content with my fix.

It is interesting that object.c does *not* contain the implementation of Python object. That is tucked inside typeobject.c (https://github.com/python/cpython/blob/2.7/Objects/typeobject.c#L3681). Instead, object.c contains (in Java terms) a sort of abstract base class.

This is worth considering as a design idea, but a less radical approach is to define Py.repr() that employs the same logic, and use it wherever we definitely want the bytes representation of an object, whatever an actual __repr__ throws at us. I think this may depend on further straightening out the __str__/__repr__ thing, and I don't really want to delay 2.7.2 for it.
History
Date User Action Args
2019-03-28 09:23:02jeff.allensetmessageid: <1553764982.76.0.947911697025.issue2649@roundup.psfhosted.org>
2019-03-28 09:23:02jeff.allensetrecipients: + jeff.allen, psykiatris
2019-03-28 09:23:02jeff.allenlinkissue2649 messages
2019-03-28 09:23:02jeff.allencreate