`import-self` only compares the name of a module and doesn't consider the actual module being imported

[vapier]

Bug description

# This module is named "gzip".
#!/usr/bin/python3
"""Test"""
import gzip
gzip.main()

Configuration

No response

Command used

pylint gzip

Pylint output

************* Module gzip
gzip:5:0: W0406: Module import itself (import-self)
gzip:7:0: E1101: Module 'gzip' has no 'main' member (no-member)

Expected behavior

pylint shouldn't think a program named "foo" can be imported as "foo" when it doesn't have a .py extension

Pylint version

pylint 2.14.5
astroid 2.11.7
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110]

OS / Environment

Linux

Additional dependencies

No response

[jacobtylerwalls]

Hi @vapier thanks for the inquiry. This predates my involvement by a lot, but the blame tells me this is intentional since at least #219.

[vapier]

i don't think that conclusion is correct. being able to lint programs doesn't mean they have to be registered as importable modules.

[jacobtylerwalls]

Thanks, I was having trouble understanding what you meant by "registered as an importable module." Do you mean import-self should not be emitted? (And not that the entire file should be ignored?)

In that case, having had a look at fac0b37, I guess we do have a flag we could check to see if this "was just some file" and not something importable ending in .py. (Although with some effort you could still import it, that's not relevant here, since a user who takes great effort to do that is probably not going to complain if we make import-self go away.)

If you don't mind, I'll retitle the issue to focus on import-self.

[jacobtylerwalls]

Regarding the no-member in this example, we have #5151 for that.

[jacobtylerwalls]

Maybe we should close #5151 in favor of this one and broaden the scope back out to all the other module-related checks (no-member, no-name-in-module) since we never got a response to @timmartin's reply. What do you think @vapier?