Hello, While working on my GSoC project to move PyPy’s unicode implementation to utf-8, I added support for __eq__ to RPython. It was suggested on IRC that this may be controversial and I should write to the mailing list for further feedback. I’ve pushed my changes to the rpython-__eq__ branch if you’d like to look at the code itself.
My reason for adding __eq__ support (along with other magic methods) is so that Utf8Str can be used as a drop-in replacement for the built-in (RPython) unicode type as much as possible. There are a number of places in where the same code is used to handle strings and unicode objects and make use of the standard operators. Needing to create a special case for Utf8Strs in every such place would be rather painful. Note that to prevent confusion, classes are prevented from defining __eq__ if the class at the root of their hierarchy does not do so also. This avoids the case where casting to common base hides the presence of a __eq__ method. I didn’t add such a check for __mul__ and __add__ since the * and + operators aren’t defined on RPython instances anyway and thus won’t silently behave differently post-translation like == could. Thoughts? Thanks, Tyler _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
