Re: [Jython-dev] PyObject __repr__, __str__ and toString

[Jeff A. <ja...@fa...>]

On 15/12/2018 09:13, Samuele Pedroni wrote:
> On Wed, Dec 12, 2018 at 10:35 AM Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     ...
>     PyObject.java contains some comments I've never understood and
>     have had
>     difficulty following
>     (https://hg.python.org/jython/file/tip/src/org/python/core/PyObject.java#l218).
>
>     It seems advice only relevant to those who extend PyObject, which is
>     mostly us. And we certainly don't follow it in PyObjectDerived which
>     contains the mechanism by which Python authors override __str__ and
>     where toString delegates to __repr__.
>
>
> for what is worth that comment seems to be from before new-style 
> classes support, when indeed extending PyObject was easy/natural and 
> was done also outside of the Jython code base itself often, and the 
> code was following Java patterns more than the slightly quirky 
> patterns needed to implement new-style semantics,  so telling people 
> implement toString and the runtime will do the rest made sense.

Hi Samuele,

You're right. They don't come much older.

It seems the present code tries to preserve that approach, but against 
the tide of expectation that  __str__ and __repr__should define the 
string forms. Given this is a Python object, upholding Java conventions 
against the Python data model is bound to create cognitive stress. And 
it doesn't quite work. In a proxy to a Java object, the argument runs 
the other way of course (a synthetic __repr__ or __str__ should wrap 
toString).

Assuming this is right, there is the question of user code extending 
PyObject that followed the old advice. Breakage may preclude a fix.

Jeff

PS: I'd neglected your book until recently, since it does not cover 
recent features, but I found it still good on why certain things work 
the way they do.

Jeff Allen