[pypy-dev] Work on the JVM backend

Michał Bendowski michal at bendowski.pl
Mon Jan 16 22:38:40 CET 2012



On Monday, 16 January 2012 at 13:53 , Antonio Cuni wrote:

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

I changed it to object.__hash__(self). It also occurred to me that calling compute_unique_id here would probably make sense, as it is the "stub implementation" already – am I right? Or would that be mixing PyPy levels?

As for null instances, lltype.identityhash (reused by ootype) suggests that nulls are not a valid input for identity_hash.
  
>  
> > 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.

You can find the fixes in bitbucket.org/benol/pypy in branch jvm-improvements.

Michał   




More information about the pypy-dev mailing list