#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 SimonKing):
On my way to the next conference, I thought that a "minimally invasive"
approach would perhaps be best.
By that, I mean:
I plan to NOT MOVE the current `_get_action_` method from
sage.structure.parent to sage.categories. After all, it is a cpdef
function, probably for a reason.
Consequence of that approach is that the category framework will not be
able to provide `_get_action_` as a method of the parents. I want to point
out that this is actually an advantage.
I plan to change `Parent.get_action` (without underscore), so that
1. the output of `self._get_action_(...)` is taken into account; this
agrees with the general idea that methods specially written for a parent
have precedence over the categorical general nonsense. If it returns
something not None, then it is used.
2. if None was obtained in the first step, `super(Parent,
self)._get_action_` is taken into account. THIS can be obtained from the
category framework. If it returns something not None, then it is used.
3. discover_action is called.
Only the second step is new. The advantages of my approach are:
- The category framework CAN provide an action via
`ParentMethods._get_action_`. So, it is not needed to learn something new.
One simply does for !ParentMethods what one has previously done for
Parent.
- It is conceivable that we have a parent P such that `P._get_action_(S,
...)` returns None for a specific parent S. but the category framework
actually knows an action. In that situation, the category framework can
provide that action, even though a method defined for the parent has
precedence in the method resolution order over a method obtained from the
category.
- There is no need to change existing implementations of `_get_action_`
(this is what I mean by "minimally invasive")
Let's see if that works!
--
Ticket URL: <http://trac.sagemath.org/ticket/18756#comment:23>
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.
