Fix annotation of decorated methods, nested methods, nested classes #91
Conversation
The determination of the name of a function is currently done by looking at the function node and its grandparent node (for the class), and nothing else. This misses the class name for decorated methods as well as producing nonsensible results for nested classes and functions (though none of the frontends handle those right yet either). Fix this by doing a full traversal up the tree and including all functions and classes. The broken decorator behavior was also sort of accidentally causing the class name to be left off for staticmethods and classmethods (which the collector does also), so we need to keep supporting that behavior.
| a = """\ | ||
| class C: | ||
| @staticmethod | ||
| def nop(cls, a): |
| class C: | ||
| @staticmethod | ||
| def nop(cls, a): | ||
| # type: (int) -> int |
There was a problem hiding this comment.
The signature if incorrect for a static method.
| b = """\ | ||
| @dec | ||
| def foo(): | ||
| # type: () -> int |
There was a problem hiding this comment.
What happens if the decorator does not preserve the signature?
What happens to argument types?
There was a problem hiding this comment.
This is the pyannotate fixer. Its job is to just insert type annotations that are handed to it. That's a question for whatever the frontend producing the annotation is.
| def get_funcname(name, node): | ||
| # type: (Leaf, Node) -> Text | ||
| def get_funcname(node): | ||
| # type: (Optional[Node]) -> Text | ||
| """Get function name by the following rules: | ||
|
|
||
| - function -> function_name | ||
| - instance method -> ClassName.function_name |
There was a problem hiding this comment.
Maybe update the docstring?
| return funcname | ||
| components = [] # type: List[str] | ||
| while node: | ||
| if node.type in (syms.classdef, syms.funcdef): |
There was a problem hiding this comment.
Should this do something about async defs?
There was a problem hiding this comment.
It doesn't need to, since async_funcddef contains a funcdef, and that's what gets passed in. I'll add a test, since this means that "async methods" are one of the other things fixed by this.
The determination of the name of a function is currently done by
looking at the function node and its grandparent node (for the class),
and nothing else. This misses the class name for decorated methods as
well as producing nonsensible results for nested classes and functions
(though none of the frontends handle those right yet either).
Fix this by doing a full traversal up the tree and including all
functions and classes.
The broken decorator behavior was also sort of accidentally causing
the class name to be left off for staticmethods and classmethods
(which the collector does also), so we need to keep supporting that
behavior.