-
-
Notifications
You must be signed in to change notification settings - Fork 410
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
Add T20 ruff rule (print calls) #6849
Conversation
848607a
to
f1b210d
Compare
@jni, I switched to |
# References Tracking issue: #5589 # Description This PR adds a few rules to be checked by `ruff`. Some of them required no changes or very little; you can click on individual commits to see them one by one. ~The only one that needs discussion is `T20` (print statements) which required a few ignores.~ EDIT: moved it to #6849 The rules are: - "ASYNC": avoid some async-related pitfalls (no changes needed) - "EXE": ensure shebangs and executable permissions match (1 change) - "FA": ensure `from __future__ import annotations` is used correctly (1 change) - "LOG": ensure loggers are used correctly (no changes) I'm going through a few more, but might split out into separate PRs. Happy to split this one out as well. ~EDIT: depends on #6775~ No longer true, rebased on main and it's fine.
@jni input appreciated! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6849 +/- ##
==========================================
- Coverage 92.45% 92.43% -0.02%
==========================================
Files 614 613 -1
Lines 55166 55153 -13
==========================================
- Hits 51002 50983 -19
- Misses 4164 4170 +6 ☔ View full report in Codecov by Sentry. |
This PR changes 11 prints to print # noqa, and 7 prints to logging/warn. (And note that for our purposes logging is in fact equivalent to print.) imho, that is a bit of a smell that the rule is too stringent and we should not activate it. I'm not actively going to block it but yeah, I don't love it. |
napari/utils/notifications.py
Outdated
except Exception: | ||
print( | ||
print( # noqa: T201 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to change this to logging.exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brisvag and this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this a place where we want the user to see it? So maybe warnings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this code, I think that warning may not be rendered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But warnings should show up as popups right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets do this this way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe not. The logging.exception
will also print exception information. There is no equivalent for warnings. If you prefer warning, then we should print stacktrace somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, logging is fine by me then. We should really get a custom handler going afterwards :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but do we still raise after? I guess so?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above raise.
@@ -405,9 +405,11 @@ def _debug_tb(tb): | |||
QApplication.processEvents() | |||
QApplication.processEvents() | |||
with event_hook_removed(): | |||
print("Entering debugger. Type 'q' to return to napari.\n") | |||
print( # noqa: T201 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loggin.info
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how to deals with these cause I'm not familiar with this module. Isn't this print here on purpose so the traceback can be shown to the user?
And we should change this. We should implement a custom logger grabber and GUI to inspect logs from application. |
Ok I'm convinced. Maybe changing the remaining prints to logs then makes sense. |
It's more like "at least half of our prints shouldn't be there" :P Also, this rule is more to prevent accidentally adding prints to places where they shouldn't be; the few prints that should be there (e.b the outputs of the cli) are already there and are unlikely to change. Agree it's not a super-important rule, but I think it does more good than bad. Agree we should have a log handler we grab everywhere! It could be done as part of this PR as well. @Czaki I'm not sure I follow the GUI comment; can you elaborate? |
Something like icy Output tab: Or console log in ImageJ. So place where it will be accessible to user who launch napari without a terminal. It may be even smarter (like runtime level filtering, or selection of which logger output should be published). |
I think it should be part of the default installation
No. Output of |
Definitely not this PR, but I agree that it would be nice to just have it somewhere. As long as we use logging properly, we should be able to do this at a later stage.
Yeah, and a couple other things! @Czaki: what's the general idea behing using |
warnings are shown as modal dialog in the bottom-right corner and logging is not displayed. I think that warning is something that should be immediately displayed to the user and logging for later access. |
But don't we want the warnings to the user to also be displayed in the logs? Wouldn't it be cleaner to take all logs from level |
For example, warning by default provides deduplication of events (with well, known bug). And logging push to logs every event that happens. Warnings were introduced in python 2.1 and logging in python 2.3 (based on documentation). Warnings are global, logging offers the option to have multiple loggers with different settings. I see that there are similar, but not equivalent. I'm not sure if we want to change every logging into notification. |
I changed 1 more print into log, but I think the rest should remain I also moved the import time to a benchmark based on the implementation at https://github.com/proost/pandas/blob/master/asv_bench/benchmarks/package.py. Let's see if it works :) |
The Qt benchmark run requested by PR #6849 (09eb7e3 vs 1dcbade) has finished with status 'failure'. See the CI logs and artifacts for further details. |
The Qt benchmark run requested by PR #6849 (cd2d5da vs 1dcbade) has finished with status 'success'. See the CI logs and artifacts for further details. |
@brisvag It looks like the last merge to main introduced merge conflict |
# We don't stop on error because if you switch around branches | ||
# but keep the same config file, it's easy for your config | ||
# file to contain targets that aren't in the code. | ||
print(f'Patcher: [ERROR] {exc}') | ||
logging.exception('Something went wrong while patching') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we not log the exception message itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
logging.exception
logs the exception without passing it explicitly by doing some magic inspection of the stack trace!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤯
Can you add a comment above it pointing that out? Cos that is just batshit crazy. 😂
LOL @brisvag literally the day after you merge this, with much resistance from me:
😅 |
References and relevant issues
Tracking issue: #5589
Previous discussion: #6840
Description
As asked in #6840, I split out this more controversial rule from it, so we can discuss it separately.