-
Notifications
You must be signed in to change notification settings - Fork 803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove std::endl from print functions #2018
Comments
I sympathize, but I don't want to break existing workflows on current behavior. However, there is a solution: phase out print (in a few releases) in favor of streaming. Some classes already support ostream, with no prefix or endl. If you wanted to make a PR with that (and where you can use it in print, to avoid duplication), that would be a very worthwhile contribution. Could be done one subfolder at a time, e.g, starting with geometry. |
PS how to surface that in python to support {} would have to be looked into; the wrapper should maybe hook up to streaming rather than print. |
I see what you mean. For future reference, I think the place to modify would be gtsam/wrap/gtwrap/pybind_wrapper.py Line 142 in 814a734
|
This is easy to do in the wrapper once we have full streaming support. :) |
The current python printing is a shortcut to just wrap the old |
Furthermore, we can (and should!) support the custom formatting in Python with BTW the |
Issue
Currently, classes append
std::endl
in their print statements, such asPose2
:It seems to me that this is unnecessary and goes against best practice. It means that users have less control over how they can format their print statements. For example, I would have liked the Python code
to yield
but instead it gives the following:
This example also demonstrates best practice as followed by Numpy, which does not automatically insert newlines.
Solution
Remove
std::endl
from print functions. Perhaps it can be implemented so that the endline is only added if the user has not supplied a prefix string. I can create a PR if this solution is desired.Caveats
This is an opinionated issue, but I think that allowing the user to format their strings how they wish is strictly better than the current approach. The optional string prefix is handy for debugging and writing quick statements, but for even slightly more elaborate formatting it gets in the way.
The text was updated successfully, but these errors were encountered: