Closed mscheltienne closed 3 months ago
To me if you did mne_bids.something(...)
in the interpreter the correct line to get in the warning is the current input
one. Typically it's most informative and standard to emit the caller line rather than the something
OK, I did not notice this was using mne.utils.warn
and not directly warnings.warn
, so indeed the caller line is returned which can be informative.
In an ideal world, we would get both the caller line and the line where the warning was emitted (stacklevel=1, to quickly jump to the warning line and figure out why it was emitted in the first place). I use this second option very often.
Anyway, for now I removed that erroneous stacklevel=2
part.
Attention: Patch coverage is 92.30769%
with 2 lines
in your changes are missing coverage. Please review.
Project coverage is 97.60%. Comparing base (
87eea28
) to head (81ae67d
). Report is 18 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
mne_bids/commands/mne_bids_crosstalk_to_bids.py | 50.00% | 1 Missing :warning: |
mne_bids/commands/mne_bids_mark_channels.py | 50.00% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In an ideal world, we would get both the caller line and the line where the warning was emitted (stacklevel=1, to quickly jump to the warning line and figure out why it was emitted in the first place). I use this second option very often.
In theory it should be a few lines to add an add_caller=False
to mne.utils.warn
that uses the adjacent stack frame calling function somehow like:
<ipython-input-blah>:1: RuntimeWarning: In call to mne_bids.something: Converting data files to BrainVision format
then mne-bids could make use of it.
Maybe we'd even want add_caller=True
by default...?
@larsoner That's a nice idea, and would give the caller
line, but only as text right? VSCode terminal does some nice magic to enable a Ctrl + click
on the emitted warning to jump to the line.
With that proposition, the caller line would not benefit from the same 'link' to jump to the definition; and thus without this I don't see the added benefit compared to quickly searching for the error string within the codebase.
Anyway, I will give it a try and see how it renders ;)
Let's keep this PR as a simple string format fix then, mark for merge if happy :)
PR Description
I propose to change the
stacklevel
of a couple of warnings I encountered, becauseis really not that informative and I would appreciate to quickly jump to the function issuing the warning.
While I was on it, I fixed probably all the occurrences of
"blabla" "bla"
strings. I don't believe this minor maintenance PR needs a changelog entry.Merge checklist
Maintainer, please confirm the following before merging. If applicable: