[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.


More information about the pypy-dev mailing list