#18756: Use coerce actions in the category framework
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.8
Component: coercion | Resolution:
Keywords: cython, coercion, | Merged in:
actions, categories | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | e1111c346a82639bb41161469754d45008117801
u/SimonKing/combinatorial_free_module_cython_coercion| Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by jdemeyer):
Replying to [comment:6 nthiery]:
> Yup, the single inheritance of Cython is a very strong constraint.
Just a comment on this: one thing which is possible is inheriting from an
extension type (a.k.a. `cdef class`) and a Python class, the result being
a Python class. For example, in
`src/sage/rings/number_field/number_field_ideal.py`, there is
{{{
class NumberFieldFractionalIdeal(MultiplicativeGroupElement,
NumberFieldIdeal):
}}}
where `MultiplicativeGroupElement` is an extension type and
`NumberFieldIdeal` is a Python class (the extension type must be first in
the MRO). Of course, you lose the advantage of a fast Cython `_mul_` call.
I also agree with !SimonKing that inheriting from `RingElement` is not
really a problem and that the current design of having a huge number of
`...Element` types might not have been the best design.
--
Ticket URL: <http://trac.sagemath.org/ticket/18756#comment:17>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
