[pypy-dev] Work on the JVM backend
Antonio Cuni
anto.cuni at gmail.com
Mon Jan 16 13:53:12 CET 2012
On 01/16/2012 01:03 PM, Michał Bendowski wrote:
> I have copied the hash(self) from ootype._instance – didn't consider subclasses messing with __hash__. Anyway, as compute_identity_hash is defined as the RPython equivalent of object.__hash__(x), the "stub implementation" in _builtin_type (and _instance) should just return object.__hash__(self), am I right?
indeed, I suppose that also _instance._identityhash should be changed, even if
for this particular case should not change much (because hash() is implemented
in terms of id() for instances).
It *might* play a role for null instances, because as you can see _null_mixin
overrides __hash__. So, if you decided to change it you should make sure that
there are tests which checks for the identityhash of null instances, or write
one if it doesn't exist :-).
object.__hash__ is implemented in terms of id(), so for our use case it
doesn't change much. Personally, I think that using id() is better because
it's obvious that the values of two different objects cannot collide, but
using object.__hash__ works too.
> Sure. Do you want me to fix the mentioned problems in new commits or modify the patches using mq? I'm new to Mercurial and don't really know what is the preferred workflow.
doing more checkins is fine, we do it all the time. Personally, I prefer more
a list of commits which shows the errors and their fix than a list of commits
which are "perfect" but hide the path that leaded to them.
ciao,
Anto
More information about the pypy-dev
mailing list