Don't resolve Callable NamedTuple fields to their return type #6576
Conversation
`NamedTuple` fields are always marked an properties. In certain situations, this causes their type to be determined incorrectly when they hold `Callable`s, resolving to the `Callable`'s return type rather than the `Callable` itself. This prevents that and fixes python#6575.
|
I am going to look at the bug you filed and think a bit about the whether this is the best approach (or whether, as you suggested, we should change something on the namedtuple side setting properties), but separate from that: could you please add a test. |
mypy/subtypes.py
Outdated
| @@ -622,7 +622,7 @@ def find_node_type(node: Union[Var, FuncBase], itype: Instance, subtype: Type) - | |||
| if isinstance(node, FuncBase) or isinstance(typ, FunctionLike) and not node.is_staticmethod: | |||
| assert isinstance(typ, FunctionLike) | |||
| signature = bind_self(typ, subtype) | |||
| if node.is_property: | |||
| if node.is_property and not node.info.is_named_tuple: | |||
There was a problem hiding this comment.
Hm, it looks like this will still do bind_self on the type, which I think might cause trouble, since it will modify the type of the field in an unexpected way. Make sure to test with multiple arguments.
There was a problem hiding this comment.
Looking at https://github.com/python/mypy/blob/master/mypy/checkmember.py#L495, it seems that only is_initialized_in_class vars get the property/self binding treatment, so probably the right approach is to match that.
|
Thanks for the response! Yeah, I'll take a stab at adding some tests for various scenarios, including where the |
|
Thanks for the pointers here! I changed the 'self' binding check to match the code/condition you linked to 🙂 I also added some integration tests. I haven't really worked with this codebase much before, so I wasn't sure if there's a way I should try to make these work in the I did notice that a |
There was a problem hiding this comment.
Thanks!
Just writing end-to-end typechecker tests is totally fine and pretty standard for mypy. While we have some unit tests, the easiest way to specify programming language constructs is generally with concrete syntax so...
The TestPEP561 are frustratingly fragile. Are you testing inside a venv? TestPEP561 uses a virtualenv and nesting virtualenvs inside venvs and vice-versa tend to break in "interesting" ways.
|
Thank you for you help and quick responses/turnaround! Don't think I was in a |
NamedTuplefields are always marked an properties. In certain situations, this causes their type to be determined incorrectly when they holdCallables, resolving to theCallable's return type rather than theCallableitself. This prevents that and fixes #6575.