> > In that case I would go with the construction that Simon proposed, have > completely different parents. And define a coercion from grading-preserving > morphisms to shift-by-0. No need to have a single parent for > perhaps-shifted morphisms, and you can leverage the existing framework > instead of figuring out yourself how to compose morphisms. > > IMHO its fine to have a _repr_ with many branches, that only proves that > you are trying to make the notation concise. The more important question is > can you implement the operations without lots of special casing. > > This won't work with the current framework for Hom though -- we currently can't pass optional arguments though Hom(). Now that's easy enough to fix, but documenting the optional args seems tricky to me. I don't know of a good place to put the necessary information that is easy for the user to find. Whereas if we had one parent, we could easy document the inputs which give the different element classes.
Best, Travis -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
