#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Hi Nils!
Replying to [comment:475 nbruin]:
> This [https://groups.google.com/forum/#!topic/sage-devel/lODVhZRT4RE
sage-devel thread] is probably a good real-world example for how careful
one should be messing about with attribute lookups and mro manipulations
in python:
>
> To avoid the need to explicitly chain parts of the `__init__` process,
the category framework supplies `__init_extra__` hooks, which should get
executed for all the classes in the mro. It does so by looking for
`__init_extra__` entries in each of `[C.__dict__ for C in class.mro()]`,
or something roughly equivalent.
>
> Problem: that doesn't test whether attributes are present if classes
implement a custom `__getattr__`. And Parent does that, to ensure that
dynamic classes get faked for `cdef` classes. So `__init_extra__` has
never worked properly for `cdef` classes.
Thanks for investigating!
I definitely agree: playing with `__getattr__` is generally best
avoided, as it deviates from standard inheritance and is just a can of
worm when it comes to robust introspection and the like. Back in 2009,
it took a long discussion until I could make my point that the
approach of changing the class of the parent to a subclass inheriting
from the category classes was a much better solution :-)
The current `__getattr__` hack for Cython classes is just a
workaround, but as far as I know, we have no better solution for
now. And as long as this will be the case, the support for categories
will always be somewhat fragile for Cython classes. I am not surprised
that the __init_extra__ fails. I probably stumbled on it at some point
and I should have documented it in a ticket; this is now #15718: do
you mind adding some example from the discussion on sage-devel there?
Thanks!
But there is hope: I have discussed this a couple times with Robert
Bradshaw, and there is no theoretical obstacle in having a Cython
class support multiple inheritance from a hierarchy of *abstract
classes*. It just has not been implemented.
As a general comment, combining the performance of statically compiled
code with the flexibility that dynamical approaches give for
genericity is a hard problem that can't be tackled at once. I very
much would like to see more developers that have a genuine need for
Cython classes get their hands dirty improving the category framework
in this direction. In particular pushing for the appropriate
feature(s) in Cython. And fixing #15718 (which should be easy). But
that's for another thread, probably on sage-devel.
By the way:
- As much as Cython can be critical for implementing elements, in
particular for low level arithmetic, as much one needs to consider
twice the added value of having a Cythoned parent.
- The __init_extra__ protocol is usually best avoided when it comes to
assigning values to attributes, as this is not a lazy enough. Lazy
attributes are a better bet, especially since Simon's hard work to
make them work properly for Cython classes.
- The current protocol handling the .one() method is too convoluted,
in particular due handling backward compatibility. With a bit of
refactoring of legacy code, in particular around polynomials, it
probably could and should be simplified. Simon: do we already have a
ticket for this?
> It may well be that axioms defer to already-existing black magic for
these things, in which case this ticket doesn't really make things better
or worse in this respect, but it is clear that the scenario above was not
considered by the designers of the category framework before, so it's
worth checking how the code here is affected by it.
This ticket is only about the construction of categories (which are
Python classes), and all the magic happens at this level. So we should
be safe.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:476>
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/groups/opt_out.
