inspect.Parameter checks that name is an identifier, but does not check for keywords
#92062
Labels
Comments
Zac-HD
added a commit
to Zac-HD/cpython
that referenced
this issue
Apr 30, 2022
|
I can see a scenario where this will break things: we try to get the signature for a function implemented in C that takes a positional-only argument with a name that happens to be a keyword. I can't find any instances of that pattern in typeshed or CPython, but they may exist elsewhere. |
|
Hmm, that makes sense. I'll tighten the check to only apply if the |
Zac-HD
added a commit
to Zac-HD/cpython
that referenced
this issue
Apr 30, 2022
Jelle pointed out that this might occur in C functions, and so to avoid breaking any existing (if strange) code we'll only check params which can be called with named arguments.
|
I think we're fine to continue ignoring unicode names which normalize to keywords, since that's the existing behaviour of >>> def f(dｅf): # non-ASCII "e" in argument name
... print(locals())
... f(1)
{'def': 1} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the following code:
This parses, but it doesn't compile:
fromis a keyword and so the code is syntactially invalid.The problem is that
inspect.Parameterchecks that the given name is an identifier, but doesn't check that it's not a keyword. You can thus create invalid signatures, which cause considerable confusion on downstream introspection:We're fixing this downstream in HypothesisWorks/hypothesis#3317 and pydantic/pydantic#4012, but I think that
inspect.Parameter("from", ...)should also raise an error, just as if the provided name was not an identifier at all.The text was updated successfully, but these errors were encountered: