[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