-
Notifications
You must be signed in to change notification settings - Fork 795
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
refactor: Reduce SchemaValidationError
traceback length
#3530
refactor: Reduce SchemaValidationError
traceback length
#3530
Conversation
No information is lost, still available on hover. The comment itself is not helpful to users and would be presented on every validation error
Moved repeat info to *Notes*, which should come last https://numpydoc.readthedocs.io/en/latest/format.html#notes Removed redundant *Returns* Minor changes to improve readability
Saves 2 lines, identical result, maybe faster due to not allocating an intermediate dict
All `...ChannelMixin` already use this form. Saves 2 lines
Saves only 1 line, but collapses the dict comp. The `:=` expr doesn't reduce lines, but does reduce characters
Saves 2 lines, avoids repeating the 3 kwargs - but allows modified `context`
As with the change to `SchemaValidationError`, the information is available in a docstring if needed. But no longer is displayed to the user on a validation error
Removes 5 lines. Has the additional benefit of replacing an identical block in `SchemaBase.validate_property`. Therefore reduces the maintenance burden of keeping comments in sync
…copy)` The call to `.to_dict`, and 3 line comment also appeared in the traceback for validation errors on `ChartType`s. This removes the need for the comment and type ignore that it is describing. See vega#3480 for more info on the introduction of `_top_schema_base`
Discovered during debugging that the rhs always evaluated as `type`, which was not intentional
Just to keep things consistent
Should achieve greater consistency across the public API
I started reviewing this yesterday and should be able to finish today. It would be good if one more person has at least a quick glance at it. |
Thank you @joelostblom |
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.
Thanks for the thought and work and you put into this @dangotbanned ! A special shout out to your commits messages, which are always so detailed and explanatory; I have found this really helpful when reviewing. In fact, you have inspired me to write more elaborate commit messages myself! (although I wish github's PR review UI had an easy way to see the messages on a line per line bases when in the files
view, and not only when going commit by commit...)
Overall, I think the shorter error messages you introduce here add utility, and I believe you have largely avoided that this comes at the expense of code readability, which is important and something we want to be careful with. I have a few comments and I would like someone else to have at least a quick look before merging, in case there is something I'm missing here.
Really appreciate the compliment and review @joelostblom! Yeah it is a shame the messages aren't always easy to find. Hopefully #3530 (commits) addresses your comments.
I agree on having another set of eyes. |
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.
LGTM now, I'm approving but let's get another approve before merging.
but I'm starting to think using a conversation thread might make for an easier review.
The little I have tried, I have found it more convenient to write down my thoughts in a commit message right after I make each change to the code, rather than storing it somewhere and pasting it as a comment once the PR is made. Ultimately, I think this is a Github UI issue, it should be possible to view the commit message line by line and quote it in a reply when reviewing in the files tab.
Thanks again @joelostblom Just disabled auto-merge to support this #3530 (comment) |
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.
Completed a semi-thorough review and LGTM as well. Thanks @dangotbanned! Before seeing the "Before" and "After" in your PR description, I never realized how long these tracebacks are but now it bugs me that we didn't fix this sooner ... :D
This PR was prompted by difficulty in reading the traceback of failures in #3501.
SchemaBase.to_dict
#3501 (comment)Description
There has clearly been a great deal of care put into using
schemapi.SchemaValidationError
to produce a more useful traceback.An element that I believe was overlooked, was that the surrounding code also contributes to the traceback length.
Before/After
The exact traceback seems to vary by the python interpreter used.
ipython
could be considered the best-case, withpytest
the worst-case.Anything else I imagine would fall somewhere between the length of each.
ipython
Reduction of roughly 10 lines
Importantly, long comments that are not relevant to the user are no longer displayed.
Before
After
pytest
Reduction of roughly 60 lines
Before
After
Notes for reviewers
I was very careful in slowly introducing these changes & ensuring each commit passed the test suite.
Therefore, the commit messages contain a lot of information which explain each decision.
A general theme was to move long comments into docstrings, and reduce lines & characters where possible - to reduce noise.