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