super-init-not-called false positive in .pyi files

[DetachHead]

Bug description

class Foo:
    def __init__(self): ...

class Bar(Foo):
    def __init__(self): ...

Configuration

No response

Command used

pylint foo.pyi

Pylint output

foo.pyi:14:4: W0231: __init__ method from base class 'Foo' is not called (super-init-not-called)

Expected behavior

no error

Pylint version

pylint 3.0.0a7
astroid 3.0.0
Python 3.11.2 (tags/v3.11.2:878ead1, Feb  7 2023, 16:38:35) [MSC v.1934 64 bit (AMD64)]

OS / Environment

No response

Additional dependencies

No response

[DanielNoord]

@Pierre-Sassoulas It feels like a lot of messages might not make sense for .pyi files? (Why complain about too many methods if you're only describing what is already written somewhere else?)

Perhaps we should tackle this in a broader effort? Or just call the support experimental and indicate that it is work in progress.

[Pierre-Sassoulas]

I'm on mobile so I can't link to the comment where the same problem hapen with another message, but I agree with you: this would benefit from design upfront instead of waiting for an issue related to each message to be opened.

[DanielNoord]

That doesn't look like something we will fix before 3.0.1. Should we amend the changelog to indicate that this is WIP?

[Pierre-Sassoulas]

Are we going to create a list of (un)authorized message for pyi later ? If so I don't see any downsides if we start the implementation with the currently known list of message that should not be raised on pyi in 3.0.1 and either complete it later or invert the conditional to make it an allow list when we get to it ?

[mbyrnepr2]

I think the original issue was interpreted different ways by different people; for example some probably want Pylint to ignore no-member warnings if objects can be found in .pyi files but that may be controversial among Pylint maintainers because there is another issue open somewhere with comments suggesting that Pylint shouldn't trust the type-hinting and instead rely on our own inference. (perhaps it was this issue: #4813 I'm thinking of? Also this astroid PR: pylint-dev/astroid#2216)

I agree this needs a separate issue with a full specification otherwise we have no position on what Pylint intends to do regarding interface files.

[Pierre-Sassoulas]

I now realize that there was expectations close to #4813 when asking for pylint to be analyzing pyi files. Right now, we have a bunch of nonsensical checks (super-init-not-called being one), plus all the annoying convention checks (invalid name?) but without inference coming from analyzing the body of the function that would permit to raise accurate important error messages. We closed #4987 (yeah 🎉 !) but that might not be what thumbs-uppers in this high priority issue expected.

So to be clear I'm proposing to remove the nonsensical messages that we're currently aware of in 3.0.x, then think about what's nonsensical globally in 3.1.0. In the mid to long term, Taking types into account in pyi as if they were inferred make a lot of sense imo (a lot more than if we also have the content to actually infer from) but that is probably a discussion that needs to happen thoughtfully in #4813.

[DetachHead]

I think #9097 is another big issue relating to .pyi support

[mbyrnepr2]

Well said @Pierre-Sassoulas 👍

[kkroening]

FWIW, this temporary workaround of configuring pylint globally for *.pyi via .pylintrc seems to work reasonably well:

[pylint.*.pyi]  # workaround for https://github.com/pylint-dev/pylint/issues/9096
disable=
    invalid-name,
    super-init-not-called,
    unused-argument,

[DetachHead]

another workaround is to use basedpyright instead which improves on pyright's reportMissingSuperCall rule. more info here