-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Adjusting the signature of a function on the basis of caller types in plugin #10216
Comments
I've stumbled into the same issue and can't see any better way.
Also, I found |
If we address this, we should update the docs here w.r.t "Note that argument types aren't available yet": Lines 423 to 426 in a9bc366
("use a method hook instead" should've said "use a function hook instead" in this case -- copy-pasta) Notably this comment is in @sobolevn's #9102 which added this hook, so this looks at least somewhat intentional, but I can't tell if there's a really good reason. |
Validate `attr.evolve` calls to specify correct arguments and types. The implementation makes it so that at every point where `attr.evolve` is called, the signature is modified to expect the attrs class' initializer's arguments (but so that they're all kw-only and optional). Notes: - Added `class dict: pass` to some fixtures files since our attrs type stubs now have **kwargs and that triggers a `builtin.dict` lookup in dozens of attrs tests. - Looking up the type of the 1st argument with `ctx.api.expr_checker.accept(inst_arg)` which is a hack since it's not part of the plugin API. This is a compromise for due to #10216. Fixes #14525.
@ilevkivskyi let's have #15369 resolve this one too? |
Validate `dataclassses.replace` actual arguments to match the fields: - Unlike `__init__`, the arguments are always named. - All arguments are optional except for `InitVar`s without a default value. The tricks: - We're looking up type of the first positional argument ("obj") through private API. See #10216, #14845. - We're preparing the signature of "replace" (for that specific dataclass) during the dataclass transformation and storing it in a "private" class attribute `__mypy-replace` (obviously not part of PEP-557 but contains a hyphen so should not conflict with any future valid identifier). Stashing the signature into the symbol table allows it to be passed across phases and cached across invocations. The stashed signature lacks the first argument, which we prepend at function signature hook time, since it depends on the type that `replace` is called on. Based on #14526 but actually simpler. Partially addresses #5152. # Remaining tasks - [x] handle generic dataclasses - [x] avoid data class transforms - [x] fine-grained mode tests --------- Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
What is the proper way to adjust the signature of a function basing on actual caller types?
I have two ideas:
FunctionContext.api.fail
every time when arguments are invalidAre there any better ways?
The text was updated successfully, but these errors were encountered: