Question: Should toString use __repr__ or __str__?

[hoodmane]

In #4037 (comment) @Duncanr-glitch said:

the toString method using the __repr__ method just seems incorrect since there's a distinction between __repr__ and __str__ that python devs expect and sometimes rely on. Using __repr__ when doing a bare console.log makes since, but not when a dev is trying to string the object.

Looking at the history, toString was added here: 9579aa9
I am not aware that we've ever discussed what this should do. I personally don't have a strong opinion. Interestingly, toString is missing from our proxy table, we should probably update the table in any case.
https://pyodide.org/en/stable/usage/type-conversions.html#proxying-from-python-into-javascript

@rth @ryanking13 @antocuni what do you all think?

[antocuni]

Same as you, I don't have a strong opinion but I have a very mild preference for __str__: JS doesn't even try to do anything useful with toString() anyway, ([object Object] anyone?), so both python methods are equally reasonable, but __str__ has a more similar name :)

[rth]

I have a very mild preference for str

Same for me. +0.5 for using __str__.

For repr, I find it weird that if you take for instance x: str = "1" in Python and call repr on it you would get "'1'", which then is different from the behavior in JS. At least for strings, if we were proxy rather than convert, __str__ matches the current behavior. So maybe would then make sense to do it for proxies as well.

[ryanking13]

I'm also +1 for__str__. To be more precise, +1 for str (PyObject_Str) than repr (PyObject_Repr), as str will fallback to __repr__ if __str__ does not exist.

[hoodmane]

Okay, since all are agreed that using __str__ is preferable, I will open a PR. Does anyone object to changing this in v0.24.0? Maybe we should add a flag to opt into the old behavior with a deprecation period?

[ryanking13]

Maybe we should add a flag to opt into the old behavior with a deprecation period?

This sounds good to me.