The "rename" feature was always a bit odd. Does anybody use it? I think it
comes up occasionally on sage-devel but, so far, inertia always won.
Also, the fact that SageObject has a __hash__() in the first place is
dubious. Only immutable object should be hash-able, not everything under
the sun. Though by now we probably have lots of people using mutable
objects as dictionary keys, so its probably difficult to change.
In terms of immediately actionable items to improve pickling, I think we
should first stop pickling caches. If only to be able to have reproducable
doctests that don't depend on what has been cached before.
We should also check (using the TestSuite) that __reduce__()[1] doesn't
link back to the object being pickled, since that is not supported by
Python.
On Tuesday, September 17, 2013 10:15:14 AM UTC+1, Simon King wrote:
>
> Hi Nils,
>
> On 2013-09-16, Nils Bruin <nbr...@sfu.ca <javascript:>> wrote:
> > If we change the first line to base=SageObject, we get an attribute
> error,
> > which can be traced back to the definition of __hash__ (defined on
> > SageObject) trying to call __repr__ . Thus, we can say that SageObject
> > breaks pickling on circular structures, in that things that work
> perfectly
> > fine when inheriting from "object", break when we use SageObject
> instead.
>
> I am of course not the person who created SageObject. But I think I can
> see the rationale for how its hash is implemented: In Python's <object>,
> the default is that comparison is by identity, and hence the hash is
> obtained from the object's address in memory, id(). In Sage, we are more
> likely in a situation where non-identical objects evaluate equal. Hence,
> if we want a default hash at all, then it should take this into account.
> And it is a good guess that two Sage objects evaluate equal only if their
> string representations are equal (but not "if and only if").
>
> Some problems, though: The string representation is not always available
> when we need the hash. Computing the string representation is quite
> expensive, and hence the default hash is very slow; but at least it is
> cached now, as of version Sage-5.12.beta5. And, worst: The string
> representation can be customized after object creation, and so the hash
> value depends on whether the hash was first called before or after
> renaming. Example:
>
> sage: class MyParent(Parent): pass
> sage: P1, P2, P3 = MyParent(), MyParent(), MyParent()
> sage: repr(P1)==repr(P2)==repr(P3)
> True
> sage: P2.rename("foobar")
> sage: P3.rename("foobar")
> sage: hash(P2)
> 3433925302934160649
> sage: P2.reset_name()
> sage: P3.reset_name()
> sage: repr(P1)==repr(P2)==repr(P3)
> True
> sage: hash(P2)==hash(P3)
> False
> sage: hash(P1)==hash(P3)
> True
>
> Hence, the hash of P2 and P3 are different, simply since the hash of P2
> has been computed before the name was reset.
>
> I have no recommendation what we should do.
>
> Best regards,
> Simon
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
