pylance forces the import from typehint.

[phi-friday]

Environment data

• Language Server version: 2023.4.40
• OS and version: macOS Ventura 13.3.1
• Python version (& distribution if applicable, e.g. Anaconda): pyenv 3.10.11 + poetry venv

Expected behavior

### before
from sqlalchemy.types import TypeDecorator

class Test(TypeDecorator):
    def dialect_impl

### after
from sqlalchemy.types import TypeDecorator

class Test(TypeDecorator):
    def dialect_impl(self, dialect: Dialect) -> TypeEngine[Any]:
        return super().dialect_impl(dialect)

Actual behavior

### before
from sqlalchemy.types import TypeDecorator

class Test(TypeDecorator):
    def dialect_impl

### after
from typing import Any
from sqlalchemy.engine.interfaces import Dialect
from sqlalchemy.sql.type_api import TypeEngine
from sqlalchemy.types import TypeDecorator

class Test(TypeDecorator):
    def dialect_impl(self, dialect: Dialect) -> TypeEngine[Any]:
        return super().dialect_impl(dialect)

Logs

in 2023.4.40

(3191) Background analysis message: setFileOpened
(3191) Background analysis message: markFilesDirty
(3191) Background analysis message: setFileOpened
(3191) Background analysis message: markFilesDirty
(3191) [FG] parsing: .../test.py (1ms)
(3191) [FG] binding: .../test.py (1ms)
(3191) Background analysis message: analyze
(3191) [BG(1)] analyzing: .../test.py ...
(3191) [BG(1)]   parsing: .../test.py (1ms)
(3191) [BG(1)]   binding: .../test.py (0ms)
(3191) [BG(1)]   checking: .../test.py (18ms)
(3191) [BG(1)] analyzing: .../test.py (19ms)
(3191) Background analysis message: resumeAnalysis
(3191) Background analysis message: getSemanticTokens delta
(3191) [BG(1)] getSemanticTokens delta previousResultId:1683022949096 at .../test.py (1ms)
(3191) Background analysis message: getDiagnosticsForRange
(3191) Background analysis message: getDiagnosticsForRange
(3191) Background inlayHint message

in 2023.4.30

(3065) Background inlayHint message
(3065) Background analysis message: setFileOpened
(3065) Background analysis message: markFilesDirty
(3065) [FG] parsing: .../test.py (1ms)
(3065) [FG] binding: .../test.py (1ms)
(3065) Background analysis message: analyze
(3065) [BG(1)] analyzing: .../test.py ...
(3065) [BG(1)]   parsing: .../test.py (0ms)
(3065) [BG(1)]   binding: ...test.py (0ms)
(3065) [BG(1)]   checking: .../test.py (7ms)
(3065) [BG(1)] analyzing:.../test.py (7ms)
(3065) Background analysis message: resumeAnalysis
(3065) Background analysis message: getSemanticTokens delta
(3065) [BG(1)] getSemanticTokens delta previousResultId:1683022783984 at .../test.py (1ms)
(3065) Background analysis message: getDiagnosticsForRange
(3065) Background analysis message: getDiagnosticsForRange
(3065) Background inlayHint message

more

I downgraded to 2023.4.30 and it worked fine.
"python.analysis.autoImportCompletions": false has already been added to the setting.

[rchiodo]

Thanks for the issue but this is by design. It's importing the missing imports when you complete the method. Without those imports it wouldn't run.

This was actually an enhancement:
#4200

[phi-friday]

Thank you for your answer @rchiodo .
If it's by design, how can I turn it off?

and, Is this also intended to ignore TYPE_CHECKING?

ex:

## before
from typing import Any, TYPE_CHECKING
from sqlalchemy.types import TypeDecorator

if TYPE_CHECKING:
    from sqlalchemy.engine.interfaces import Dialect
    from sqlalchemy.sql.type_api import TypeEngine

class Test(TypeDecorator):
    def dialect_impl

### after
from typing import Any, TYPE_CHECKING
from sqlalchemy.engine.interfaces import Dialect
from sqlalchemy.sql.type_api import TypeEngine
from sqlalchemy.types import TypeDecorator

if TYPE_CHECKING:
    from sqlalchemy.engine.interfaces import Dialect
    from sqlalchemy.sql.type_api import TypeEngine


class Test(TypeDecorator):
    def dialect_impl(self, dialect: Dialect) -> TypeEngine[Any]:
        return super().dialect_impl(dialect)

[rchiodo]

If it's by design, how can I turn it off?

There's no way to turn it off. I guess don't use completions for methods would be the way to not have it happen at the moment.

The part where it skips TYPE_CHECKING seems like a bug though. It should recognize those imports I believe.

[phi-friday]

Thank you for your answer @rchiodo .

If this is a bug, would it be better to keep this issue open?
I'm not used to using github community yet, so I'm not sure what to do.

[erictraut]

@phi-friday, why are you placing these imports under a TYPE_CHECKING conditional? Any time you do this, you are effectively "lying" to the type checker about the code that will be executed at runtime, and this can hide bugs or errant conditions that the type checker would otherwise be able to detect. It's akin to buying a car with "blind spot" detection but then placing tape over the sensors. I recommend avoiding the use of TYPE_CHECKING if possible.

And I'm not convinced that pylance should be be adding auto-imports to import statements that are located within conditional blocks.

[rchiodo]

You can close the issue or not based on if you're satisfied with the results. We'll also do the same after the rest of the Pylance team gets a chance to look at it. I think the TYPE_CHECKING part is a bug, so we should keep it open.

We may also add a setting to turn off this auto completion, but that would depend upon more people asking for the same thing.

[erictraut]

I think the TYPE_CHECKING part is a bug

I don't think this is a bug. Auto-imports shouldn't be added to import statements in conditional blocks because those import statements may not be executed, which will result in a runtime exception when the symbol is later referenced.

I suppose it would be possible to determine whether pylance is introducing a use of the symbol only for purposes of a type annotation and the use of that type annotation happens to be deferred (e.g. the file contains a from __future__ import annotations or is a stub file) and the conditional block is guarded only by a TYPE_CHECKING test. In that particular circumstance, you could safely special-case it and allow auto-import for an import statement within the conditional block. But that's a very specific circumstance that involves a coding practice that I would not recommend in the first place.

So I think the current behavior is "by design", and this is a feature request.

[phi-friday]

@erictraut

When I define task in airflow, I have to delay the point where import is executed.
In that case, I use TYPE_CHECKING if I want to add a type hint.

I think that's definitely the special case you mentioned.
I don't want it to be added under the conditional blocks, but I think it's okay if it's not duplicated.

[debonte]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[jamespreed]

It would be nice to be able to turn off the automatic additions of import statements. Reasoning: I often use to accept the autocompletion, knowing that I will be changing the output type. For instance

class TextCleaner:
    def __call

Hitting here will autocomplete the __call__ method with the function signature, but I will change the output type hint from Any to str. Auto-adding the import adds extra deletion steps.