#11935: Make parent/element classes independent of base rings and the category
graph consistent with method resolution
---------------------------+------------------------------------------------
Reporter: SimonKing | Owner: nthiery
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.7.3
Component: categories | Keywords: parent class, element class,
category
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies: #11900
---------------------------+------------------------------------------------
Comment(by SimonKing):
A problem may be seen in pickling. Before explaining the problem, let me
remark that I don't see a big concern for "pickling a parent class": What
we actually want to pickle is a ''parent'', not just a naked class. The
serialisation data of a polynomial ring, for example, will comprise the
base ring, the generator names and the term order, but certainly the class
of the polynomial ring will not be part of the pickle.
However, if we do want to serialise a naked parent or element class, we
have the following problems:
Currently, `C.parent_class` is pickled by `getattr, (C,"parent_class")`.
The pickling data (hence, C) is part of the cache key of a dynamic class.
With that, the parent class of different categories C1 and C2 can't be the
same.
I see three approaches to get rid of it.
1. Remove the pickling data from the cache key of dynamic classes
2. Make pickling of `C.parent_class` just rely on the default way of
pickling a dynamic class
3. Work around the cache of dynamic classes, but still use
`getattr,(C,"parent_class")` for pickling.
I think 1. is not gonna happen. It would break a lot of code, I suppose.
I had tested 2. and 3. while working on #11900. Both would work, but there
are different conerns concerning long-term stability.
2. means:
The pickle of a parent class will only depend on the category graph as it
was on the time of pickling. If the category graph changes between
pickling and unpickling the parent class, you would get a ''different''
class.
3. would be a bit more stable.
The idea is:
(i) In the lazy attribute `parent_class()`, the dynamic class is first
created ''without'' providing the reduction data (as in approach 2.).
(ii) Before returning that dynamic class, it is tested whether the
reduction data is still none. If it is, the `getattr, (C,"parent_class")`
thingy is inserted.
Consequence: `Algebras(QQ).parent_class` could, for example, be unpickled
as `Algebras(GF(2)).parent_class` - which is not a big problem, since we
want them to be the same. However, if in a distant future we want them to
be different again, we'd be in trouble...
I suggest that I create patches for both 2. and 3., and then people can
tell what they think about it. The method resolution will then be taken
care of by another patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#comment:2>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
