On Mon, Nov 10, 2008 at 07:13:58PM -0800, Robert Bradshaw wrote:
> If I understand your code correctly, what you're proposing is that to
> declare an Parent/Element to be a member of a category, one creates
> the category and then dynamically creates classes at runtime that
> need to be inherited from. Using QQ[x] as an example, I would create
> the category
>
> C = JoinCategory(EuclideanRings(), Algebras(QQ))
>
> and then inherit from the dynamically created C.parent_class() and
> C.element_class().
That's the idea. But I see this as an implementation detail that the
average programmer should not have to play with. So actually I have
modified the Parent.__init__ constructor to do this automatically for
you. See the Category documentation a bit lower in my patch on
sage-combinat; here is a short extract:
We now construct a parent in the usual way:
sage: from sage.categories.category import build_class
sage: class myparent(Parent):
... def __init__(self):
... Parent.__init__(self, categories=[Ds()])
... def g(self):
... return "myparent"
... class Element:
... def method(self):
... return "myparent"
sage: D = myparent()
sage: D.__class__
<class '__main__.myparent_with_categories'>
Something similar should be done for elements: the class would be
built automatically from the Element class of the categories and of
the parent itself. This is not implemented yet.
Note that the classes created dynamically are cached. So most of the
time two parents coming from the same place (e.g. VectorSpace(3, QQ)
or VectorSpace(3, RR)) would share the same underlying class.
One drawback: the current implementation uses a hack (which is well
localized but still a hack): the Parent.__init__(self) method changes
the class of self on the fly to the newly created one. How robust is
this, in particular w.r.t. cython class?
> Actually, if I wanted to sit down and write my super-optimized QQ[x]
> (say, by wrapping FLINT) I'm not even sure how I'd go about doing
> that. It's also unclear how this would fit into the coercion model
> (where the cdef classes Element and Parent use on c-level methods
> and attributes for speed). But you do avoid needing to implement a
> __getattr__ method.
Yup. I indeed don't know yet how this fits with pure cython classes
(but see my other post about subclasses of cython classes). I am
hoping that something semantically equivalent can be implemented, but
for this I need you. The main thing is: do you foresee any blocker for
this design to be adapted to cython classes one way or the other.
> Not currently, which is unfortunate. I'm glad you're taking up the
> banner to change this :).
:-)
Nicolas
--
Nicolas M. Thiéry "Isil" <[EMAIL PROTECTED]>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
