`typing.Literal` can cause false-positive import

[Jasha10]

Hello,

Unfortunately I have a bug to report. I'm getting a false-positive import with certain typing.Literal usage.

before running autoimport:

from typing import Literal as L

var: L["* time"] = "* time"

after running autoimport:

from typing import Literal as L
import time

var: L["* time"] = "* time"

Importing the library time is not correct.

Context:

This bug came up when using the nptyping library, which encourages liberal use of Literal.

Environment:

$ python -c "import autoimport.version; print(autoimport.version.version_info())"
           autoimport version: 1.2.2
               python version: 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:39:04) [GCC 10.3.0]
                     platform: Linux-5.13.0-35-generic-x86_64-with-glibc2.31

[lyz-code]

Hi @Jasha10 thanks as always for opening the issue. I was able to reproduce the bug, although I think the solution should be done in the upstream library we use to detect import errors. We blindly trust autoflake to detect import errors, and they are giving a false positive with your code when they shouldn't. If it's critical for you, I'm happy to accept a PR to prevent this issue until it's fixed in autoflake. Although maybe it's easier to use the next snippet that works as expected:

from typing import Literal

var: Literal["* time"] = "* time"

What do you think?

[lyz-code]

Weird, I've tried to reproduce the error with autoflake --check script.py but it returns no issues even if you run it on the next snippet:

os.getcwd()

Which should say that os is not imported. Nevertheless autoflake.check is what we use to detect the import errors.

I was going to suggest that you showed them the output of autoflake -c script.py but it looks like it's not a good idea, unless you want to open another issue xD

[Jasha10]

I was going to suggest that you showed them the output of autoflake -c script.py but it looks like it's not a good idea, unless you want to open another issue xD

Haha! Yes, that's strange indeed :)
Both autoflake -c script.py and even autoflake script.py seem to be no-ops.

Anyway, I've opened an issue against autoflake: PyCQA/autoflake#109.

If it's critical for you...

It's not super critical -- I'm happy to wait until we hear back from the autoflake folks :P