Hi Peter, On 2013-09-24, Peter Bruin <pjbr...@gmail.com> wrote: > We already have FieldElement, which is a Cython class consisting of > methods, including is_unit(). Ignoring my opinion about C.ElementMethods > for a moment, why not just move the existing methods in > FieldsElementMethods to FieldElement and then set Fields.ElementMethods = > FieldElement, and similarly for other Element classes? (With or without > static inheritance between the Cython classes, whichever makes it work.)
According to my earlier posts: I of course believe that this would make sense. Perhaps Nicolas reads this and can comment: What reason has there been to not derive Fields.ElementMethods from FieldElement? Of course, surprises may happen when one runs the doc tests. I remember one "funny" issue: I wanted to create a Python class simultaneously inheriting from the two Cython classes RingElement and Morphism. But it led to doctest errors. If I understood correctly the Cython developers agreed that this was a bug in Cython: It confused cdef public attributes of the two base classes. So, one never knows what happens if one changes things in a reasonable way. Best regards, Simon -- 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/groups/opt_out.
