Any additional methods that are provided will _not work_ if they do not have access to the RefFrame objects (in order to know how to transform between coordinates). Your proposal does not explain how these RefFrame objects will be accessed.
Because of this, the only advantage of subclassing Add and Mul that I see is that it will have garbage checks (which as I mentioned can be postponed to precondition checks in any of the functions to be implemented). On the other hand it keeps all the disadvantages mentioned by Matthew (Add and Mul make many assumptions, that you will keep by subclassing them). So, if you want new container classes for any of the reasons mentioned by Matthew, subclassing Add and Mul does not seem the right way - you should start from Basic as it is done in MatExpr. On the other hand, as I mentioned in the last two paragraph, I do not think you have given appropriate reasons for creating new container classes. If the main reason for new container classes is garbage checks you can just use MatExpr (its add, mul, matsymbol, etc). This MatExpr approach has another unrelated advantage: the author of MatExpr (Matthew) has both addressed most (probably not all) of the issues that are problematic for diffgeom, mechanics or quantum in terms of following sympy conventions and he is still very active within the project so you will be able to question him for details (sorry to volunteer you like that, Matthew ;) -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
