#18756: Use coerce actions in the category framework
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: sage-6.8
Component: coercion | Resolution:
Keywords: cython, coercion, | Merged in:
actions, categories | Reviewers: Travis Scrimshaw
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | fe7226d9e28d1dbf4130e8b57fb09885bd76226c
u/SimonKing/combinatorial_free_module_cython_coercion| Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Hi Simon!
Replying to [comment:23 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!
Thanks for investigating!
I definitely see the point of having a protocol allowing for a
`_get_action_` method to state in certain cases "oh, never mind; I
actually have nothing to say in this case, just do the usual stuff
from super".
However the above implementation is not uniform: we could imagine use
cases where a category may want to implement such a `_get_action_`
that occasionally returns `None`. Or a class `B` inheriting from `A`
itself inheriting from `Parent`, where `B._get_action_` may want to
return `None` to specify: use `A._get_action_`.
So, to weight the pros and cons my questions are:
- How invasive would it really be to move `Parent._get_action_` to
`Sets.ParentMethods`? Does it actually requires to update anything
else in the Sage code?
- super calls would be the natural thing to do here. Alas super and
categories don't work so well together. Still, could we find a
reasonable enough syntax for this that we could advertise in the
documentation of `_get_action_`.
- Shall we investigate for a more uniform protocol where `get_action`
would try each `_get_action_` method along the MRO until one returns
something else than `None`?
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/18756#comment:31>
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.
