Hi William, On 19 Apr., 07:24, William Stein <wst...@gmail.com> wrote: > So the main issue I pointed out above, namely that SageObject has a > __hash__ defined, is really a non-issue, since that's the standard > default convention in Python anyways. The real issue to consider is > whether using the string representation as a default is a good idea. > The only real drawback is efficiency, since computing the string > representation of an object can be costly. So...
It is not just costly but may result in an infinite recursion. It is imaginable that computing the string representation depends on cached methods. One flavour of cached methods is @cached_in_parent_method: * You have an element, and you have certain data that belong to the element, but are cached in its parent. * The key to access the data will contain the element. * Hence, you need the hash of the element. * Hence, by default, you need the element's string representation. * And, if you aren't lucky, the string representation relies on a cached_in_parent_method. That's one of the things that I noticed when I tried to speed up Sage by extensively using the improved cached methods from #11115. So, I guess that using id for the hash seems more reasonable to me, and seems to be the Python default as well. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
