Scope the log level set by verbose to the call - #175
Merged
Merged
Conversation
`load_xdf(verbose=...)` set the level on the module logger and never restored
it, so a single call reconfigured logging for the rest of the process. It also
broke the documented meaning of `verbose=None` ("use root logger level") for
every later call: once the logger has a level of its own, it no longer inherits.
An application that had configured `pyxdf` to its liking would silently lose
that configuration to any library that happened to pass `verbose`.
Contributor
|
Why a decorator though? |
Contributor
Author
What did you have in mind? Wrapping it into a context manager or a try/finally would lead to a lot of indentations. And resetting "manually" before each return seems a bit more unclean 🤔 |
Contributor
|
Yes, a decorator is cleanest here. I've tweaked it a little bit though:
However, all of this wouldn't be necessary if we removed |
Contributor
|
Thanks @sappelhoff! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
load_xdf(verbose=...)sets the level on the module logger and never restores it:So one call reconfigures logging for the rest of the process. Two consequences:
pyxdfto its likingloses that configuration to any library that happens to call
load_xdf(verbose=False)—silently, and from code the application does not own.
verbose=None. The docstring saysNone"willuse root logger level", which holds only while the logger's own level is
NOTSET. Afterany earlier call that passed
verbose, the logger has a level of its own and no longerinherits, so every later
verbose=Nonecall silently keeps the old setting.The fix restores the level when the call returns, via a small decorator so the body of
load_xdfis untouched and its signature is preserved throughfunctools.wraps:verbosekeeps working exactly as documented during the call; it just no longer leaks outof it. Restoration happens on the error path too, which is where a leak is most likely to go
unnoticed.
load_xdfis the only function that needs this: it is the only place in the package thatcalls
setLevel.resolve_streamsandmatch_streaminfostake noverboseand neverchange the level, so they log at whatever level is in effect, which is the correct behaviour
for a library.
Tests
test/test_logging.py, 7 cases, no data files needed — they use a nonexistent path soload_xdfraises after the level has been set:verbosein(None, True, False)verbose=Truecallverbosestill decides whether the "Importing XDF file" record is emitted, so the fixcannot be mistaken for deleting the feature
Against the current release these fail as expected —
assert 10 == 40, the logger left atDEBUGwhere the application had setERROR.pytest test/: 366 passed, 13 skipped, 1 xfailed.ruff checkandruff format --checkclean.
Note
Deliberately left alone:
load_xdfsets the level onpyxdf.pyxdfrather than on thepyxdfparent, so while a call is in flight it still overrides a level set on the parentnamespace. Now that the override is scoped to the call, that is a much smaller wart, and
changing which logger is addressed would be a behaviour change rather than a fix. Happy to
follow up separately if you would rather it addressed the package logger.