#11935: Make parent/element classes independent of base rings
------------------------------------------------------------------+---------
Reporter: SimonKing |
Owner:
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-5.10
Component: categories |
Resolution:
Keywords: parent class, element class, category | Work
issues:
Report Upstream: N/A |
Reviewers: Nicolas Thiery, Travis Scrimshaw
Authors: Simon King | Merged
in:
Dependencies: #9138, #11900, #11943, #12875, #12876, #12877 |
Stopgaps:
------------------------------------------------------------------+---------
Comment (by SimonKing):
Hi Nicolas,
Replying to [comment:106 nthiery]:
> > But the first problem arises if the base class of H is an extension
> > class. Then, `H.__class__` can't be overridden, and thus inheritance
> > from the abstract class is by the custom `__getattr__` of Parent,
> > which is slow compared with proper inheritance.
>
> Right, but that's no different than for other parents and element. We
> have lived with it so far, and as long as Cython won't allow multiple
> inheritance from purely abstract classes we will have to. But there is
> hope: Robert mentioned several times that there is no theoretical
> barrier and that it just needs to be implemented :-)
I don't see how multiple inheritance comes into play. What we want is to
override the attribute `__class__` of an instance. That's possible in
Python, but impossible in Cython, and I don't think this can ever change.
So, it is ''not'' an option to use `_initalise_category_` to enrich the
class of a homset H, if `H.__class__` is a cython class.
But what we ''can'' do, if I am not mistaken: Create a dynamic class that
is constructed from one concrete base class (which can be a cythoned
Homset, for example) and an abstract class (which can be
`C.hom_category().parent_class`). And then we could create `H` as an
instance of this dynamic class.
> Not anymore! Line 306 of homset.py, with the patch applied, if no
> _Hom_ method is provided by the parent or the parent class, then Hom
> resorts to:
> {{{
> H = Homset(X, Y, category = category)
> }}}
>
> which creates H as an instance of the concrete base class Homset with
> the appropriate category.
Really? So, how does the abstract class comes into play, then? I guess I
should look at the patch...
> > And even worse things happen in
`sage.categories.rings.Rings.HomCategory.ParentMethods.__new__`, which is
a very ugly hack that should be avoided IMHO.
>
> You mean in sage.categories.schemes, right?
No, in the location I stated. It is:
{{{
sage: sage.categories.rings.Rings.HomCategory.ParentMethods.__new__??
Type: instancemethod
String Form:<unbound method HomCategory.ParentMethods.__new__>
File: /home/simon/SAGE/prerelease/sage-5.9.rc0/local/lib/python2.7
/site-packages/sage/categories/rings.py
Definition:
sage.categories.rings.Rings.HomCategory.ParentMethods.__new__(cls, X, Y,
category)
Source:
def __new__(cls, X, Y, category):
"""
sage: Hom(QQ, QQ, category = Rings()).__class__
# indirect doctest
<class
'sage.rings.homset.RingHomset_generic_with_category'>
sage: Hom(CyclotomicField(3), QQ, category =
Rings()).__class__ # indirect doctest
<class
'sage.rings.number_field.morphism.CyclotomicFieldHomset_with_category'>
"""
from sage.rings.homset import RingHomset
return RingHomset(X, Y, category = category)
}}}
> > If you agree, then I'd say we try to finalise the patch here in the
> > way you suggested, namely without allowing base classes. And in a
> > second step (I think I have opened an according ticket 2 or 3 years
> > ago) we could implement the model I sketched.
>
> I'd say: as you suggest, let's finish the patch as is (hopefully with
> the __new__ removed). Then let's move on to the other functorial
> construction patch. Then cythonization of homsets / #10668 / ... Then,
> with the experience, if we find ourselves implementing _Hom_ methods
> too often, we can introduce a nicer protocol like the one you propose
> to only provide a class.
OK.
Best regards,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#comment:107>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
