-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
typing.NamedTuple false positive no-member for methods #1628
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
Comments
I have encountered the same problem. Unsure if it is a bug or if Pylint expects NamedTuple to be used as in 3.6.0 (methods could not be defined on NamedTuples then). A (slightly annoying) workaround to make pylint happy is to have an intermediate data class: class ExampleData(NamedTuple):
mything: int
class Example(ExampleData):
def as_string(self):
return f'{self.mything}' But definitely not ideal. |
I've stumbled upon the same issue. Note that creating the namedtuple using |
Also hitting this. Is there any plan to fix this issue? |
There is no plan to fix this per se. As with every issue, we'll get to it once we have time on our plate, there are hundreds of issues that needs a limited attention in one way or another. |
This is fixed in astroid's master. Please give it a go and let me know how it works! |
Hello this bug still occurs with the latest versions available: Name: pylint
|
The fix wasn't backported to 1.9 branch, the only way to get it is to use the pre-release for 2.0 with |
Awesome news. Thank you for the quick response. |
typing.Namedtuple are collections.namedtuple in disguise. We do quite a lot of work around understanding namedtuples, but we weren't doing the same for typing.NamedTuple. In order to get a consistent experience, we moved typing.NamedTuple inference support in the brain file corresponding to collections's namedtuple, and there we can leverage the namedtuple inference rewriting functions. Now a new capability that typing.NamedTuple has is to understand that we can define methods on the class, so that they can be used on the instance when instantiated. Another small bug that was fixed was to put Name nodes in .bases when building a namedtuple, instead of putting the class node itself. Close pylint-dev/pylint#1628
I'm using Writing: """Example"""
from typing import NamedTuple
class _Point(NamedTuple):
x: int
y: int I get the error:
I tried writing So, on the one hand @PCManticore said this is in pre-release just 17 days ago, so it makes sense this isn't published yet. But on the other hand he said "pre-release for 2.0" which seems to be available already. Is it actually pre-release for version 2.1? |
@orenbenkiki This issue is about the |
Oops, my bad. I got thrown by the error listed in the example above. Should I open a separate issue for it then? |
Orenbenkiki wrote:
@PCManticore I did my best identifying an issue explicitly addressing this problem, but could not find any and the pylint --version output
|
@jhbuhrman yes, please. |
Created #2459 just now. |
Awesome, thank you! |
@PCManticore Problem seems to persist in latest versions:
ran on following code:
gives result:
|
Thanks @officialcryptomaster I can reproduce this. Probably your example uses a different code path than my fix from pylint-dev/astroid@5e30daa. |
@PCManticore thanks for the quick reply. Is there an open issue for this? Would you be able to check and port the fix some time soon? |
Ah I see you reopened the issue! Thanks. Would be good if I have an approximate idea of when it might be fixed... I am for now moving to just using |
@officialcryptomaster I don't have any timeline for this fix, if you want feel free to tackle it in a PR, but it's not on my priority list for now. |
Shouldn't this issue be left open to track resolution of this bug? |
I agree with @ankostis this issue seems to have been accidentally close as part of an unrelated MR. I'm still getting an error as demonstrated in the original description with the following:
|
Please ignore my previous comment.This issue is now being tracked in #3876 |
For some obscure reason setting generated-members=DISTROS\. in pylintrc makes the pylint run flaky, causing failures like: curtin/commands/install_grub.py:93:19: E1101: Instance of 'Distros' has no 'debian' member (no-member) curtin/commands/install_grub.py:155:28: E1101: Instance of 'Distros' has no 'redhat' member (no-member) These failures: - happen on about 15% of the time, at least on Bionic - also happen with the latest stable version of pylint (2.8.2) - only happen on install_grub.py (which only refers to debian and redhat) - do not seem to happen on Impish. - possibly related: pylint-dev/pylint#1628 But the truth is I don't understand why generated-members=DISTROS\. even works some of the time for some generated members. Let's replace it with the explicit list of the (non auto-detected) generated members, so it will always work, and we'll know why it does.
Steps to reproduce
This is only legal in python 3.6.1 and higher:
$ cat nt.py
In python 3.6.0 though you get the following error:
Expected behavior
I would expect the existing member to not error.
I would also kind of not expect
Too few public methods
on subclasses oftyping.NamedTuple
, but I have so many data objects that I just have that disabled globally anyway.The text was updated successfully, but these errors were encountered: