-
Notifications
You must be signed in to change notification settings - Fork 635
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
Use a single warning interface. #4593
Comments
What is the specific problem that you're facing? Is it about seeing the same message twice or filtering messages? I agree that it's not super-elegant to have both warnings and logging but it is nice to have a programmatic "exception-like" thing happening with warnings while having a lot flexibility with logging. Some background: Most people do not enable logging, especially not beginners (few people probably know about Logging hasn't been enabled by default because we had considered this the domain of more experiences users who would also use logging in their own scripts/programs. Our default logger also creates a file (mdanalysis.log) and we don't want to write files unless the user asks for it. Are you suggesting that we enable logging to console by default (while keeping logging to file optional) and get rid of warnings? |
Interesting, I didn't know about it either.
That sounds tricky at first consideration, couldn't downstream/end users depend on the usual (i.e., |
I use MDAnalysis as a dependency of my own Python package. My package uses a lot of functions that both log and throw warnings. I often share scripts with users and collaborators via google colab. Interestingly, google colab seems to display Furthermore, if using |
I feel like someone at some time gave me a pretty good overview of they process for doing warnings and it was great - I'll have a dig around for if. I do think a review of when we use UserWarnings should be done. My longer ramble: DeprecationWarning are clean and simple - they should be noisy and annoying because they shouldn't be hit downstream if you can avoid it. UserWarnings probably shouldn't be invoked every time you have something that could be expected but just doesn't follow convention - systems without elements or similar imho should fall under this, if you just expect folks to manually guess after the fact then are you just telling them about their system or are you warning them? I.e. if I'm catching a lack of elements I'm try/excepting on an empty elements attribute, not a UserWarning. |
FYI: For another project I got convinced to switch to loguru to replace logging. |
Is your feature request related to a problem?
Currently, MDAnlysis is using both the
logging
module and thewarnings
module to warn users, even within the same file. e.g. MDAnalysis/coordinates/TRJ.py useslogging
on line 151 andwarnings
on line 280. This makes it difficult for users to interact with warnings in a singular way.Describe the solution you'd like
A single warning interface, preferably
logging
, would allow users better control when handling warning messages.Describe alternatives you've considered
Alternatively, MDA could provide it's own methods for handling warnings, however, that would likely be a lot more work.
Additional context
The text was updated successfully, but these errors were encountered: