Preferred way to include printing functionalities

[Pedro Xavier]

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 methods for printing inside the class definition (e.g. physics.vector.vector.Vector) and I've seen methods being implemented directly into the printer (e.g. vector.basisdependent.BasisDependent). My question is: which way of handling printing is preferred?

[Jason Moore]

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 Pedro Xavier <pedroxa...@gmail.com> wrote:

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 methods for printing inside the class definition (e.g. physics.vector.vector.Vector) and I've seen methods being implemented directly into the printer (e.g. vector.basisdependent.BasisDependent). My question is: which way of handling printing is preferred?

--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c478a183-ced3-4971-b851-0f8128cbd1b6n%40googlegroups.com.

[Aaron Meurer]

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 code in the printer itself is that any
time someone does a code cleanup in the printers they will apply it to
the physics printers as well. It also makes it easier for those
printers to reuse internal helper functions in the printers. I've
noticed that the physics objects have had a lot more printing bugs
than most other SymPy objects.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1Ai4Y-z9g%2Bpbf_XXCPdZSMEZjrwNp%3Dcv8Ddk7WHJ8ixACA%40mail.gmail.com.

[Jason Moore]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J8dCbxrsOxfM_5FV2qJDFfhNrqQoFHWwsgwOiH%2BVCfVg%40mail.gmail.com.

[Aaron Meurer]

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AiP7rDO6WuzvyG3qqeqNwmJdvcd%3DvLEyZqHu1fT8xdTng%40mail.gmail.com.