Specify stacklevel in calls to warnings.warn#327
Closed
kandersolar wants to merge 2 commits intodevelopmentfrom
Closed
Specify stacklevel in calls to warnings.warn#327kandersolar wants to merge 2 commits intodevelopmentfrom
kandersolar wants to merge 2 commits intodevelopmentfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR improves the user experience by adding stacklevel parameters to all warnings.warn() calls throughout the RDTools codebase. This causes warnings to display the line of code that triggered them (from the user's perspective) rather than internal implementation details, making debugging and troubleshooting easier for users.
Changes:
- Added
stacklevel=2to warnings in public API functions across multiple modules - Added
stacklevel=3to warnings in internal helper functions that are called by public APIs - Covers 21 warning locations across 7 files
Reviewed changes
Copilot reviewed 7 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| rdtools/soiling.py | Added stacklevel to 4 warnings (module import warning, parameter validation, and data quality warnings) |
| rdtools/plotting.py | Added stacklevel=2 to 4 experimental module warnings in plotting functions |
| rdtools/normalization.py | Added stacklevel=3 to data exclusion warning in internal interpolation helper |
| rdtools/filtering.py | Added stacklevel to 5 warnings in clipping filter functions (deprecation, data validation, and experimental API warnings) |
| rdtools/clearsky_temperature.py | Added stacklevel=2 to 2 warnings about input data quality |
| rdtools/availability.py | Added stacklevel to 2 warnings (module import warning and data quality warning) |
| rdtools/analysis_chains.py | Added stacklevel=3 to 3 warnings in internal TrendAnalysis helper methods |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
2 tasks
Collaborator
|
Closing - replaced with #476 |
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.
__init__.pyThis is a change I've wanted to make for a while: specify a better
stacklevelwhen emitting warnings. Thestacklevelcontrols which line of code is shown as causing the warning, with the default (stacklevel=1) being the call towarnings.warnitself. Increasing thestacklevelusually results in a more useful line of code being shown. For example, our current example notebooks show warnings like this:The source code line shown below the warning is not really useful to the user. In this case it's just the string literal containing the warning message; other times it's something like
warnings.warn(.... What would be more useful is to show one level up in the call stack (stacklevel=2), which would look like this:The best improvements are when the relevant higher-level call is a single line of code. Multi-line expressions are not always handled very well, for example:
Another complication is that the relevant stack level might be different depending how the function is called. For example
logic_clip_filtercan be called directly (stacklevel=2) or indirectly viaclip_filter(..., model='logic')(stacklevel=3).Regardless, specifying
stackleveldoesn't make things any worse, so I don't see a reason not to use them. This IPython blog post has a bit of interesting commentary on this topic.