Also, this might be a good idea to revisit our abuse of hashing vs. equality. I'm still very unhappy with us breaking python associative containers, which really hurts padics and/or caching. We should at least think about having separate _identical_ vs. _isomorphic_ methods, say, where only the latter involves coercion and possibly non-unique isomorphism. On the command line we could bind == to _isomorphic_, but use _identical_ in library code. Then we would have intuitive comparison and could still work with associative containers.
On Sunday, October 26, 2014 9:50:20 PM UTC, Nils Bruin wrote: > > On Sunday, October 26, 2014 2:08:27 PM UTC-7, Volker Braun wrote: >> >> Python 3 only uses __eq__, __lt__, ..... Python also provides >> functools.partial_ordering to synthesizing the remaining methods just from >> __eq__ and __lt__. We either use that or write a similar decorator to also >> deal with coercion. >> >> The __richcmp__ method is a Cython convention and doesn't exist in plain >> Python 3 (or 2 for that matter). >> > > A little more elaborately: On C-API level PyTypeObject has a > tp_richcompare slot with the interface that cython's __richcompare__ has. > Cython puts that special method in that slot for a cdef class. Python's > "python" classes inherit a tp_richcompare that dispatches to __eq__ and > __lt__ methods, probably because the constants Py_EQ etc. were deemed > unappetizing to expose on python level. > > This also means that on cython level, we should stick with __richcompare__ > by default, because dispatching to __eq__ python functions would be slow. > > >> -- 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.
