-
Notifications
You must be signed in to change notification settings - Fork 107
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
B026 - Argument unpacking after keyword argument #287
Conversation
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.
All looks good to me. I would love a second review from an AST stronger person than I am. Maybe adding my test suggestion might cover another edge case we should support but I am not sure ...
(yes it's ironic that someone so AST challenged maintains this project)
Any suggestions? |
This looks pretty good to me, with the substantial caveat that function calls can have multiple unpackings and you're only checking the first: def f(a, b, c, d):
print(a, b, c, d)
f(
*[1], # currently no lint error, because this is before the keyword and we stop at the first
d=0,
*[2], # want a lint here
*[3], # and also here
)
# prints: 1 2 3 0 @cooperlees I assume you know about greentreesnakes docs? They make me look better at AST stuff than I deserve 😉 |
Good catch! |
Sorry for the weird review requests. GH doesn't let me do it properly. |
Implementation looks great to me - thanks! Before merging I'd also want a longer/more informative message, along the lines of 'To avoid confusing or misleading calls, put star-args before keyword arguments so that the order of arguments matches the order of the parameters.'. Not delighted by that wording, but I think it's important to say why as well as what to help the user learn. And better to comment now than come back with something better a week late 😅 |
README.rst
Outdated
@@ -160,6 +160,8 @@ the loop, because `late-binding closures are a classic gotcha | |||
This check identifies exception types that are specified in multiple ``except`` | |||
clauses. The first specification is the only one ever considered, so all others can be removed. | |||
|
|||
**B026**: Argument unpacking after keyword argument. |
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.
**B026**: Argument unpacking after keyword argument. | |
**B026**: Argument unpacking after keyword argument is strongly discouraged. This behavior is uncommon and can lead to unnecessary confusion when reading the code thus making it prone to causing bugs. There was cpython discussion of disallowing but legacy usage and parser limitations make it difficult. |
+1 on more description here. A suggestion that I'm more than happy to have reworded + made better.
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.
**B026**: Argument unpacking after keyword argument. | |
**B026**: Star-arg unpacking after a keyword argument is strongly discouraged, because | |
it only works when the keyword parameter is declared after all parameters supplied by | |
the unpacked sequence, and this change of ordering can surprise and mislead readers. |
I think this is compact enough to also use as the runtime message, and explains specifically what we think is wrong (the mismatched order can be misleading) rather than non-actionable historical details.
I do like the historical details and I'd be happy to keep "There was cpython discussion of disallowing this syntax, but legacy usage and parser limitations make it difficult." with that link in the readme too, but not print it at runtime.
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.
I'm not super happy about the wording and needed to read it multiple times to understand that it indeed correctly explains the issue. Still, I have no better way so what gives. This is really hard to explain without an example TBH.
+1 on keeping the historical details to the README.
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.
Awesome. All LGTM.
Will work on #288 and release after we merge that. |
For better or worse this is already part of this function's API.
…version 4.17.3 Julian Berman (28): Make it clearer that format: regex is Python regexes in this implementation. Better wording. Bold is loud. Ignore PyCQA/flake8-bugbear#287. Fix the grammar on ErrorTree's repr when it has 1 error. Deprecate the CLI (via import or running normally). Update the Draft 3 and 4 metaschemas. Enable format validation by default in check_schema. Re-add the second test for importing jsonschema.cli Satisfy mypy's new default. Squashed 'json/' changes from ed0b855e7..0fa89d2ab Squashed 'json/' changes from 0fa89d2ab..9251ebff1 Emit a better error message for unevaluatedProperties with a subschema. Un-bundle single-vocabulary meta-schemas. Update docs requirements. Temporarily evade wpilibsuite/sphinxext-opengraph#87 Suppress epub warnings for duplicated ToC entries. Run more things with 3.11 in CI. Skip the rest of the docs builds on Windows in CI. Remove making believe we are ReadTheDocs in CI builds. v4.17.1 -> CHANGELOG Squashed 'json/' changes from 9251ebff1..78c888273 Minor fix for test case class names (for format tests). Empty strings are not valid relative JSON pointers. Durations without trailing units aren't valid durations. Update pre-commit hooks. Try fixing more Sphinx refs which fail only on Ubuntu... Fix instantiating validators with cached refs-to-bool schemas.
Closes #286.