Skip to content
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

Merged
merged 13 commits into from
May 22, 2024
Merged

Conversation

brisvag
Copy link
Contributor

@brisvag brisvag commented Apr 16, 2024

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.

@github-actions github-actions bot added tests Something related to our tests qt Relates to qt labels Apr 16, 2024
@brisvag
Copy link
Contributor Author

brisvag commented Apr 16, 2024

@jni, I switched to logging where I thought it made sense, keeping print + noqa only for the reasonable cases. Still not sure this is worth it, but at least it doesn't introduce big changes.

@brisvag brisvag marked this pull request as ready for review April 17, 2024 12:31
@brisvag brisvag added ci Continuous integration maintenance PR with maintance changes, labels Apr 17, 2024
@brisvag brisvag added this to the 0.5.0 milestone Apr 17, 2024
@brisvag brisvag requested review from Czaki and jni April 17, 2024 12:32
@brisvag brisvag mentioned this pull request Apr 18, 2024
12 tasks
brisvag added a commit that referenced this pull request Apr 19, 2024
# 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.
@brisvag
Copy link
Contributor Author

brisvag commented Apr 25, 2024

@jni input appreciated!

Copy link

codecov bot commented May 3, 2024

Codecov Report

Attention: Patch coverage is 48.00000% with 13 lines in your changes are missing coverage. Please review.

Project coverage is 92.43%. Comparing base (a9c25e6) to head (7478720).
Report is 5 commits behind head on main.

Files Patch % Lines
napari/__main__.py 50.00% 2 Missing ⚠️
napari/_qt/dialogs/qt_notification.py 0.00% 2 Missing ⚠️
napari/_qt/widgets/qt_theme_sample.py 0.00% 2 Missing ⚠️
napari/components/experimental/monitor/_monitor.py 0.00% 2 Missing ⚠️
napari/utils/perf/_patcher.py 60.00% 2 Missing ⚠️
napari/utils/notifications.py 66.66% 1 Missing ⚠️
napari/utils/perf/_timers.py 0.00% 1 Missing ⚠️
napari/utils/stubgen.py 0.00% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

@jni
Copy link
Member

jni commented May 5, 2024

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.

except Exception:
print(
print( # noqa: T201
Copy link
Collaborator

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brisvag and this?

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Collaborator

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

Copy link
Collaborator

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.

Copy link
Contributor Author

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 :)

Copy link
Contributor Author

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?

Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

loggin.info?

Copy link
Contributor Author

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?

napari/_tests/test_import_time.py Outdated Show resolved Hide resolved
@Czaki
Copy link
Collaborator

Czaki commented May 5, 2024

(And note that for our purposes logging is in fact equivalent to print.)

And we should change this. We should implement a custom logger grabber and GUI to inspect logs from application.

@jni
Copy link
Member

jni commented May 6, 2024

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.

@brisvag
Copy link
Contributor Author

brisvag commented May 6, 2024

This PR changes 11 prints to print # noqa, and 7 prints to logging/warn.

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?

@Czaki
Copy link
Collaborator

Czaki commented May 6, 2024

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:
obraz

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).

@jni
Copy link
Member

jni commented May 6, 2024

I don't think the logging console needs to be part of this PR (indeed, maybe not even this repo 😂), but rather, change every remaining print to a log. What do you think @brisvag @Czaki ?

@Czaki
Copy link
Collaborator

Czaki commented May 6, 2024

I don't think the logging console needs to be part of this PR (indeed, maybe not even this repo 😂)

I think it should be part of the default installation napari[all], but maybe outside this repo. But if @brisvag want, it could be even part of this PR.

but rather, change every remaining print to a log.

No. Output of napari --info should be printed using print, not logger.

@brisvag
Copy link
Contributor Author

brisvag commented May 6, 2024

I think it should be part of the default installation napari[all], but maybe outside this repo. But if @brisvag want, it could be even part of this PR.

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.

No. Output of napari --info should be printed using print, not logger.

Yeah, and a couple other things!

@Czaki: what's the general idea behing using warnings.warn vs logging.warning? We seem to use them randomly, maybe we should always use log?

@Czaki
Copy link
Collaborator

Czaki commented May 6, 2024

@Czaki: what's the general idea behing using warnings.warn vs logging.warning? We seem to use them randomly, maybe we should always use log?

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.

@brisvag
Copy link
Contributor Author

brisvag commented May 6, 2024

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 WARN or more and push them as notifications, instead of using two different systems? I also just confused about why python offers these two systems in the standard library...

@Czaki
Copy link
Collaborator

Czaki commented May 6, 2024

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.

@brisvag
Copy link
Contributor Author

brisvag commented May 6, 2024

I changed 1 more print into log, but I think the rest should remain noqa because they are all special cases. Let me know if you disagree!

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 :)

@brisvag brisvag added run-benchmarks Add this label to trigger a full benchmark run in a PR and removed run-benchmarks Add this label to trigger a full benchmark run in a PR labels May 6, 2024
Copy link
Contributor

github-actions bot commented May 6, 2024

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 non-Qt benchmark run requested by PR #6849 (09eb7e3 vs 1dcbade) has finished with status 'success'. See the CI logs and artifacts for further details.

Copy link
Contributor

github-actions bot commented May 6, 2024

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.
The non-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 brisvag removed the run-benchmarks Add this label to trigger a full benchmark run in a PR label May 7, 2024
@Czaki
Copy link
Collaborator

Czaki commented May 7, 2024

@brisvag It looks like the last merge to main introduced merge conflict

@brisvag brisvag requested review from Czaki and jni May 13, 2024 12:34
# 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')
Copy link
Member

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?

Copy link
Contributor Author

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!

Copy link
Member

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. 😂

@jni jni added the ready to merge Last chance for comments! Will be merged in ~24h label May 15, 2024
@brisvag brisvag merged commit 98c2e0f into napari:main May 22, 2024
34 checks passed
@github-actions github-actions bot removed the ready to merge Last chance for comments! Will be merged in ~24h label May 22, 2024
@jni
Copy link
Member

jni commented May 23, 2024

LOL @brisvag literally the day after you merge this, with much resistance from me:

~/projects/napari on monitor-fps(✗) at 0:00:15
$ git commit -a -m "Fix docstring indentation"
ruff-format..............................................................Passed
ruff.....................................................................Failed
- hook id: ruff
- exit code: 1

napari/_qt/qt_viewer.py:1070:13: T201 `print` found
napari/_qt/qt_viewer.py:1074:13: T201 `print` found
napari/_qt/qt_viewer.py:1080:9: T201 `print` found
Found 3 errors.

😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci Continuous integration maintenance PR with maintance changes, qt Relates to qt tests Something related to our tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants