Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
flaskparser.abort: add data to exception even if kwargs is empty #184
Any objection to this?
It doesn't break any existing test.
The idea is to avoid checking that exception has
Currently, I need to do
# Use one kwarg if hasattr(error, data): error.data.get(my_kwarg, default_val) # Use all kwargs if hasattr(error, data): my_function(**error.data)
With this change, I would just do
# Use one kwarg error.data.get(my_kwarg, default_val) # Use all kwargs my_function(**error.data)
And if I just want to check that args were passed, I'll do
if hasattr(error, data):
Thanks for the PR @lafrech . I think this is the right thing to do, but the
Before merging this, I'd like to hear from the Flask-RESTful maintainer(s) if there was good reason to conditionally add
Ah, that's right--forgot that the MA3 PR is MA2-compatible.
I'm torn about keeping MA2-compatibility in webargs 3. I think if we do keep MA2-compat, we wouldn't need to bother supporting two release lines in webargs.
Do you have a preference either way, @lafrech ?
I answered about MA2/MA3 in #188.
Regarding this specific change, I don't really mind. I mean, it is pretty minor. I hit this once, and after sending this PR, I realized I had to check anyway because the
Maybe you can tag this webargs 2 and leave it open until there are breaking changes worth a major release.
I can't really figure out a use case that would be broken by merging this, though. If no kwargs are passed, someone will get an empty dict instead of nothing. I'm not convinced it is a "beaking" change. But again, I really don't mind at all. It is not worth wasting too much time. Do whatever is simpler for you.
This could break code that relied on
Honestly, I don't feel too strongly either way. But whenever I have any doubt about whether something's a breaking change or not, I try to err on the side of caution.