Is too-few-public-methods (R0903) really useful?

[uriva]

This message over triggers many times, e.g. for dataclasses (or at least the backport to python 3.6).

See other examples in https://stackoverflow.com/questions/14027417/what-does-pylints-too-few-public-methods-message-mean

Consider removing altogether.

[matkoniecz]

Can you provide examples here? External sites may be changed so link only reports are not too useful.

[matkoniecz]

And the first example that I spotted, in https://stackoverflow.com/a/14027686/4130619 is a case where complaint makes a perfect sense.

[PCManticore]

@uriva As mentioned by @matkoniecz in most cases the check makes sense. If your class has a single method on it, it's probably a function in disguise. You can also configure the number of public methods with min-public-methods. But there are a couple of classes for which we should not report this, as it makes perfect sense to not have too many methods or no methods at all. This includes attrs, dataclasses, typing.NamedTuple and similar.
Given that your issue is about the removal of the method, I'm going to close this issue, but if you have an example where pylint complains about a dataclass, please open a separate issue.

[uriva]

Ok.
It might be a good idea to analyze which warnings people disable so this discussion becomes more objective.

[kuwv]

@matkoniecz @PCManticore there is one false positive where this really shouldn't trigger.

Descriptors (or class-based properties) contain only dunders (which are not technically private methods anyway since many can be called directly):

class Example:
    __get__(self, obj: object, owner: Optional[Type[object]] = None) -> T:
        ...
    __set__(self, obj: object, value: T) -> None:
        ...

I don't remember if single-method classes trigger, but a lot of common OOP design patterns use these (Additionally mixins can be lumped in this as well).

class Converter(AbstractImpl):
    def convert(self, content: Dict[str, Any]) -> str:
        ...

It's probably fine to trigger on though, but IMO a bit inaccurate in that Python is intended to be an OOP first language.

[matkoniecz]

it may be better to open new issue over commenting in 2019 one

[kuwv]

Ok, I'll create a new issue and reference this for @uriva.