#18109: Restructure IntegerListLex code
-------------------------------------+-------------------------------------
       Reporter:  vdelecroix         |        Owner:
           Type:  defect             |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.6
      Component:  combinatorics      |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Jeroen Demeyer     |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/jdemeyer/ticket/18109            |  9582a7a5248f609a2d2de02497b4b1d36d9dd96e
   Dependencies:  #18181, #18184     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by jdemeyer):

 Replying to [comment:44 nthiery]:
 > On the other hand, is it absolutely necessary to have this separation
 > between frontend and backend classes?
 > If it's a question of making the iterator code independent of
 > `Parent`
 It's a question of making the backend class independent of `Parent` yes.
 I think it's good to have, yes. It's not just the iterator, it's also the
 fact that `IntegerListsLex` acts as a Sage `Parent`.

 > Some small suggestions:
 >
 > - some of the cdef attributes could be declared as
 >   int's. E.g. `Envelope.min_length`.
 I consider that out of the scope of this ticket. These are micro-
 optimizations which can be done after we have a clearer view of the final
 design.

 > - maybe we could use the occasion to rename the attribute
 >   `IntegerListsLexIter.parent` especially if it's not a parent
 >   anymore.
 Sure, fine for me.

 > - Another small complication is having to handle pickling by hand each
 >   time. At least, would there be a way to implement `XXX.__reduce__`
 >   to return `(XXX, *)` rather than having to implement an
 >   `unpickle_XXX` function each time?
 It's certainly annoying, but that's because Cython cannot automatically
 (un)pickle extension types. I have to check if it can be simplified.

--
Ticket URL: <http://trac.sagemath.org/ticket/18109#comment:45>
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/d/optout.

Reply via email to