-
Notifications
You must be signed in to change notification settings - Fork 93
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
Check proper verbosity of mbar #379
Comments
OK, the issue is that setting verbose sends the desired text to logger.info, but doesn't actually print it. Presumably, if one sets verbose, one wants that info to be printed out in some way, but right now, it's getting lost. @jaimergp , suggestions for sending that information to where the user can see it? |
The Since |
That's why all these |
So what would your suggestion be to have the code perform how people would expect, that if they give a verbosity argument, it increases the amount of information out? What hierarchy of flags to use? Where and when to send the output out (right now, most of the output occurs near the data that is being generated). |
Ideally, there would be no
To transition from the current approach, last version of pymbar 3 should include a deprecation warning for
IIRC, there's a context manager you can use for temporary verbosity increase. The main idea is that emission/delivery are uncoupled in terms of responsibility, but it still happens synchronously if you want to. There's more info here (check the "Using handlers" section). |
I'm OK with that. However, note that a lot of people (including me) are operating in the "UNIX command" mentality, where you trigger a flag to increase verbosity. Adding functionality doesn't always improve user experience as one would like if people are not used to using the functionality. So it will have to really be well documented that one does this, and the default level should probably be verbose on, with maybe a command itself telling people how to adjust the verbosity (i.e., we set the default level, and tell them how to change it). |
Yes, I totally agree. Those "app-level" flags can still be set up internally with the context manager if necessary. That's why I have been added all those "ideally". I understand it's a big change for the end user who just wants some stuff printed to stdout. I'll try to come up with a design that addresses all of our concerns. Now that we have logging, all the configuration possibilities are there. We just need to agree on the best default config for our use case (which should be as close to the pymbar3 behavior as possible). |
Now that the PMF reformatting is in, we are getting closer to getting something that can be pymbar 4.0. @jaimergp, do you have a suggested design here for the context manager in terms of app-level flags to print expected output from the logger? |
I have been thinking about this, and we might want to implement a package-level With respect to the context manager for the |
I can try to implement this next week, if that's ok? |
I'll defer to you on what makes the most sense and is most maintainable going forward. |
Check #391 ! |
Doesn't appear to be printing out much anymore when verbose=True is set.
The text was updated successfully, but these errors were encountered: