On Jan 24, 11:29 am, Travis Scrimshaw <tsc...@ucdavis.edu> wrote: > > And now the catch: In a Cython class, you can not directly implement > > __eq__, but you *must* implement __richcmp__ instead. > > That seems strange to me...
That's just how Cpython chose to implement those routines. Instead of putting a whole bunch of slots for callables, they've packaged them via one slot, __richcmp__, with an extra parameter to encode exactly what test to do. I guess they found there was quite a bit of shared code between them and it save memory on classes. > > And that's a > > problem when cythoning UniqueRepresentation, because currently it is a > > Python class with __eq__, __ne__ and __hash__ implemented, but not with > > __richcmp__. That is NOT a problem! If you don't want to implement __le__, __lt__ etc, just return the singleton NotImplemented and then python will continue its quest on finding an appropriate way to compare. > > And the problem with UniqueRepresentation.__richcmp__ is that one has an > > obvious default for __eq__ and __ne__ (namely comparison with "is" or > > "is not"), but __le__ and other comparison must be provided in another > > class, because there is no obvious default. > > Okay. Is there any reason why we couldn't default to comparing the string > representation because I would think we would not want two different > (unique) parents to have the same repr and it would give a consistent > return? String comparison is rather slow, and creating a repr tends to be dead slow (plus it tends to allocate memory, which will give an extra source of headaches on UniqueRepresentations that tend to be tested for equality in weakref callbacks), so this is a very poor default that is inconsistent with the semantics that UniqueRepresentation introduces. Identity comparison is obviously the right equality concept for UniqueRepresentation (in particular because then MonoDict and dict have the same lookup semantics on UniqueRepresentation, which makes arguing about code MUCH easier). If you do want a different equality concept, you can always subclass UniqueRepresentation and provide your own __eq__ and __ne__. > > This problem will not be lifted. Even though I will try to provide a > > cythoned UniqueRepresentation.__richcmp__ method, it would be impossible > > to turn the Python class UniqueRepresentation into a cdef class: It > > relies on a metaclass, and that's not available for extension classes. Ouch, yes that is a fundamental problem. What one should have is a custom `__new__` on UniqueRepresentation, with the python semantics, not the cython __cinit__ (formerly called and still accepted __new__). And there you can see the problem for how to arrange that properly in inheritance (let alone multiple inheritance!). In cython, the actual memory allocation happens on subclass level because it knows the full memory layout. superclasses only get to initialize that memory. However, the whole point of UniqueRepresentation is to avoid new allocation under select circumstances and return an old instance. In cython, a superclass fundamentally can't do that. Instead, one would have to mandate creation via a factory function which can do the lookup (I guess metaclasses are just a way to formalize factory functions and incorporate them into inheritance). In the current cython programming model ensuring uniqueness cannot be done upon instantiation, because your earliest hook is `__cinit__` when the new instance already is allocated. Are all our parents currently python classes then? I guess we could have thin wrappers that simply are a multiple inheritance of a cython class (the actual implementation) and UniqueRepresentation, but in that case our parents could just as well be created by a weakly cached factory function, returning an instance of the relevant (cython) class. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
