[Python-Dev] Python-versus-CPython question for __mul__ dispatch
kevmod at gmail.com
Tue May 19 22:58:31 CEST 2015
We have a similar experience -- Pyston runs into a similar issue with
sqlalchemy (with "str() + foo" calling foo.__radd__ before str.sq_concat)
and we are working to match CPython's behavior.
On Tue, May 19, 2015 at 7:00 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Nick,
> On 16 May 2015 at 10:31, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Oh, that's rather annoying that the PyPy team implemented bug-for-bug
> > compatibility there, and didn't follow up on the operand precedence
> > bug report to say that they had done so.
> It's sadly not the only place, by far, where a behavior of CPython
> could be considered an implementation detail, but people rely on it
> and so we need to write a workaround. We don't report all of them,
> particularly not the ones that are clearly of the kind "won't be
> changed in CPython 2.7". Maybe we should?
> Another example where this same bug occurs is:
> class T(tuple):
> def __radd__(self, other):
> return 42
> lst = [ ]
> lst += T()
> which calls T.__radd__ in contradiction to all the general rules.
> (Yes, if you print(lst) afterwards, you get 42. And oops, trying this
> out on PyPy does not give 42; only "lst + T()" does. Probably another
> corner case to fix...)
> A bientôt,
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev