#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 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.

 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.

--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:475>
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.

Reply via email to