Add __str__ to all geometry classes for pretty print

[yck011522]

Add __str__ to all geometry classes for pretty print

[tomvanmele]

I wonder if the pretty print should include the attribute labels or not: @tomvanmele @gonzalocasas

Point(1.678, 2.344, 5.754) or Point(x=1.678, y=2.344, y=5.754)

At the moment, even the __repr__ functions are not consistent. For example, Point.__repr__() - Has the x,y,z while Quaternion__repr__() does not.

I propose that the str() functions do not carry attribute labels unless it is not obvious; this would allow their printout to be identical to the past. Not only is it easier to read, but fewer changes to the existing docs.

the goal is to have the __repr__ be the same as the __init__, where possible. i started doing that but certainly missed quite a few...

[gonzalocasas]

As for the proposal of not including attributes in str, I actually think the new way with attribute labels makes it more readable and despite the fact this means more updates to docs and tests in other packages, I think we should keep them.

[tomvanmele]

@yck011522 that would be great!

[yck011522]

I wonder if the pretty print should include the attribute labels or not:
@tomvanmele @gonzalocasas

Point(1.678, 2.344, 5.754) or Point(x=1.678, y=2.344, y=5.754)

At the moment, even the __repr__ functions are not consistent. For example, Point.__repr__() - Has the x,y,z while Quaternion__repr__() does not.

I propose that the str() functions do not carry attribute labels unless it is not obvious; this would allow their printout to be identical to the past. Not only is it easier to read, but fewer changes to the existing docs.

[yck011522]

@gonzalocasas @tomvanmele
Do we need some tests for these str methods? I ran into problems (those broken code parts) when I tested them in a console, so maybe a simple test to make sure the str() function actually runs, for example:

test___str__():
   p = Polyhedron.from_platonicsolid(12)
   str(p)