I am -1 on hashability-on-demand for the suggested reason: it could lead to hard-to-track-down bugs in code where we end up calling a hash of something that could be *very* implicit, input to a UniqueRepresentation or a @cached_method/function. As Nils said, the user has no business hashing a mutable object, and we should explicitly tell the user that rather than silently changing it. It violates the principle of least surprise.
Imagine a bank that gave 50% of all your deposits to charity because it thought that is what you wanted to do because you checked out a charity website, but you only would find out about this when you checked your balance. I would not be happy with this bank. Best, Travis On Wednesday, August 11, 2021 at 11:03:57 AM UTC+10 Kwankyu Lee wrote: > On Wednesday, August 11, 2021 at 7:39:14 AM UTC+9 Nils Bruin wrote: > >> The semantics are actually quite straightforward: it's >> hashability-on-demand. >> > > The demand is implicit and not explicitly demanded, like set_immutable(), > by the user. We may imagine a situation that this causes a surprise to the > user. > -- 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/3fcd3dd8-cf40-4c3d-8017-bd0208ae15e6n%40googlegroups.com.
