Is there any way to disable "useImportHeuristic"?

[BlueHamBuger]

I am working on a big python project (a lot modules and only one main) and "resolving imports relative to each file" does confuse me when importing modules.
I found #253 which is the cause of it. Its seems that "useImportHeuristic" has been enabled by default:

I'm going to close this; we actually made the above change in 2021.8.2; the heuristic is now enabled for everyone, and you can delete the unused setting.
Originally posted by @jakebailey in #68 (comment)

Is there any way to disable it?

[erictraut]

There's currently no way to disable this behavior.

Whey you say it "confuses you", what do you mean? Pylance will always attempt to resolve the import first based on import resolution paths configured in your Python environment (the sys.path list). If it's unable to resolve the import, it then walks up the tree from the location of the importing file and attempts to resolve the import from higher-level directories under the assumption that the importing module may be executed as part of script, where the script's main directory is implicitly part of the import search path.

Is this behavior leading to false negatives in your code base? Or how else do you find the behavior confusing or undesirable?

[BlueHamBuger]

Is this behavior leading to false negatives in your code base?

yeah, as i said, "I am working on a big python project", so there could be hundreds of .py files and the working tree is sort of complicated.
in such a project, the heuristic way to resolve the import could be annoying.

for example:

common
|    |─ utlis
|    |    |─ a.py
engine
|─ common
|    |─ formulas
|    |    |─ b.py
|─ tools
|    |─ c.py
scripts
|─ common

The sys.path contains only the root of working directory.
Inside c.py, while typing from common., both formulas and utlis will show up.
So if someone use from common.formulas import * instead of from engine.common.formulas import * by mistake, it would not be found until the code got executed.

[erictraut]

I'd prefer not to expose a configuration knob to control this behavior, but that's an option if this turns out to be a common enough request.

I recommend moving this to the discussion forum to see what additional feedback we receive from other pylance users.

[judej]

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

[NfNitLoop]

I'd also like to be able to opt out of this behavior.

I'm trying to help a team convert what was a loosely-organized directory full of Python files into a Python package. They're very used to being able to just import bar.py from the local directory. But that doesn't work if the code is being loaded and executed from a module as foo by python -m foo. (And TBH I still make this mistake myself.)

Pyright/Pylance are giving a false negative when checking files in the IDE and CLI, not giving an error on the import bar, which means we don't find it until runtime.

This is especially glaring because Pyright will give an error if I typo an import name to something that's not available (ex: import barrrr). So it seems to be giving a 👍 for these kinds of imports, even though they are not valid in this project.

I read up on execution environments and import resolution.

Neither mentions this useImportHeuristic exception, so according to those docs I thought that I should be able to configure this to force resolving only from the root of the project:

[[tool.pyright.executionEnvironments]]
root = "."

But no such luck.

Given that the executionEnvironments setting exists, it would seem like a prime place to opt out of this behavior.

[[tool.pyright.executionEnvironments]]
root = "."
useImportHeuristics = false  # preferably some better name for this.

This would allow a single codebase to have both modules and script files in different paths.