Jeroen Demeyer wrote: > However, I wonder why you insist on using > parent._element_constructor_(). You could for example have a fast > ElementClass.__init__() or a fast non-method function > construct_foo_element().
Yes, that's my question, more or less: for example, QQ is an instance of a Python class, and has a fast element constructor, declared as such in the parent's __init__, but defined outside the Python class, so that (if my understanding is correct, I'm quite new to all that!) when Element.__call__ calls it, it is a Cython call. (There is still a function pointer to follow somewhere, but I think it is unavoidable, and anyway if everything is in cache it may not be an issue.) This looks like a good model for me (in the case where the parent does not store any frequently accessed data), and I wonder if I am missing a reason why it is not more widely used. (And then there is the situation where the parent does store values that you want to access from C or Cython code without paying the cost of a Python attribute access, but then I see no other option than making the parent a Cython class. Is there any?) >> why are so many parents Cython classes if there are no benefits? > For rings, parents are generally Python objects... Unless I'm missing something, RDF, CDF, CC, ZZ, RLF, CLF, and most finite fields, polynomial rings and power series rings are not! -- Marc -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
