> >> Thanks Volker for writing an e-mail before the clash. >> >> To my mind, it is a complete nonsense to merge this stopgap in a rc0. We >> would have time to fix the hash issues along a development cycle starting >> from an early beta. And most of them if not all should be fixed before any >> stable release. Having a stopgap on 20 or so objects looks like "do not use >> Sage as it is broken". >> >> That being said, this stopgap is clearly mandatory! The hash is a mess >> for most Sage objects. > > > - Even without this string default issue being resolved, the equality hash > assumption is false in sage, eg Mod(3,5) == 8. > > - This issue that you seem massively worried about solving asap has been > in sage for 10 years. > > > Most elements have a canonical (string) representation, and as such, this default hash works perfectly fine (and most elements are not mutable). Adding in this stopgap could potentially kill Sage if is appears in common operations in a *stable* release. I could potentially stomach this in a beta0 release, but definitely not for a stable. It's just a molehill.
Travis -- 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/d/optout.
