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ł _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
