I was actually thinking about the printing methods that are on the
classes themselves
https://github.com/sympy/sympy/blob/master/sympy/physics/vector/vector.py#L222.
For the custom printers themselves, I can see more of a rationale for
keeping them in the physics module.
Aaron Meurer
On Thu, Apr
This is the file:
https://github.com/sympy/sympy/blob/master/sympy/physics/vector/printing.py
I believe you are correct in that it could be located with the printing
package.
Jason
moorepants.info
+01 530-601-9791
On Fri, Apr 14, 2023 at 3:18 AM Aaron Meurer wrote:
> I wonder if this is reall
I wonder if this is really necessary. I'd say as a general rule that
printing logic for things that are part of SymPy should go in the
printers themselves. The printers should already support dispatching
to non-Basic classes. Is there some other reason this is needed?
An advantage of keeping the c
For the physics objects, I recommend copying how we've done it for Vector
and Dyadic. We keep the printing code in the physics.vector modules because
these objects don't subclass from basic and need some special attention.
Jason
moorepants.info
+01 530-601-9791
On Wed, Apr 12, 2023 at 3:44 PM Pe
I'm trying to add printing functionalities to physics.vector.point.Point
and looking at other printable objects in the package I've noticed that
there are at least two ways of going about this. I've seen classes
inheriting from printing.defaults.Printable and then implementing the
required meth
