Once again: https://docs.python.org/3/reference/datamodel.html#object.__hash
__eq__ and __hash__ are tied ad the hip: overriding one prevents inheritance of the other. Python takes its contract "equality must imply identical hashes" a little more seriously than sage, so Python doesn't allow the contract to be broken by a careless partial override: rewriting one needs a rewrite of the other as well. Whether __eq__ is the right hook to tap into I don't know. If those classes participate in coercion, then absolutely not: they should implement _eq_ or something like that and let coercion do its thing before presenting elements to the class for comparison. But if these are really just container types then a simple-minded `__eq__` implementation may be sufficient (and perhaps there's nothing sensible to inherit from! I haven't checked their MRO) On Sunday, 11 December 2022 at 02:19:41 UTC-8 axio...@yahoo.de wrote: > Help needed again. I removed the (seemingly) useless overrides, but now > SetPartition and DecoratedPermutation isn't hashable anymore. Curiously, > ParkingFunction is, and I don't see the difference. > > On Saturday, 10 December 2022 at 23:45:41 UTC+1 Martin R wrote: > >> https://trac.sagemath.org/ticket/34824 now removes the parent from the >> hash, and all the overrides I could find. >> On Friday, 9 December 2022 at 23:03:38 UTC+1 Nils Bruin wrote: >> >>> On Friday, 9 December 2022 at 02:49:12 UTC-8 axio...@yahoo.de wrote: >>> >>>> Would it make sense to have a subclass, or perhaps an option to >>>> ClonableArray.__init__, that determines whether or not to include the >>>> parent into the hash? The current behaviour seems rather error prone to >>>> me. >>>> >>> >>> I think we've identified that there are definitely cases where having >>> parent *not* included in the hash for certain versions of ClonableArray is >>> beneficial. I'm not sure we have a convincing case where having the parent >>> in the hash IS beneficial. A scenario where this would be the case would be >>> if somewhere we end up with sets/dictionaries with loads of (non-equal) >>> instances of ClonableArray such that tuple(...) hashes to the same value. I >>> think it's unlikely that distinguishing on parent in the hash is ever a >>> performance-essential feature. So it may be reasonable to change the hash >>> function for all of them. >>> >>> If there are cases for both then the appropriate way is via overriding >>> the hash on subclassing, not introducing extra flags on the init method: >>> hash gets looked up via special method slots, so you should just make sure >>> that the class has the right function registered. There's a mechanism for >>> doing so: overriding methods in subclasses. >>> >>> On the other hand, I am not sure whether GF(3)(4) == ZZ(4) is desirable. >>>> >>> >>> It's basically a corollary of being able to write GF(3)(1) + 1 . You'd >>> end up with a system that is very painful to use interactively if you >>> wouldn't allow for that (but, yes: coercion through quotient maps is >>> definitely more problematic than through inclusions). >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/abd129d2-7f19-4f0f-8355-a8c57ba68c71n%40googlegroups.com.
