Two modules with identical names create a conflict

[AlexanderSher]

1. Create and open a python file in the root folder
2. Create and open python file with the same name that isn't in the root folder or any subfolders.

These two modules will have the same name. As a result, one will be overridden by the other in ModuleTable.

See also ImportTests.Completions_ImportResolution_OneSearchPathInsideAnother

[MikhailArkhipov]

Promoting, there are user-reported issues on this. @jakebailey can add links.

[jakebailey]

#1360 is the concrete example with more comments about this. Doing a depth sort as I almost did in #1289 "helps" but disallows valid import names. I'd think we need to have the following:

The import resolver doesn't do the "carving" thing anymore, and instead allows multiple names for the same module. Since we have PythonModule.Name, if we have a "canonical name" for a module, a wrapper could exist to show that "this module has this name in this context" while passing through the rest.

[MikhailArkhipov]

We most probably need this for persistence in some form so we can tell which module the type is from correctly.

[AlexanderSher]

For the fix, we need to define how module should be chosen if we have several modules matching the same name. python itself iterates through the sys.path, where executing directory is the first one.

[MikhailArkhipov]

I think there are 2 cases

• inside the product while it is running. Module name + path hash will do, I think. However, that is machine setup specific.
• persistence: name + version + file size + timestamp hash might work.

[jakebailey]

Doing it by path order is important, yeah. I'd imagine that since this ordering impacts what a module sees in its imports, the "unique ID" may need to involve that as well (i.e. if I install qt, then what pandas contains is different due to that addition, rather than being fixed).

[jakebailey]

My other thought was that we could still have a unique name in the dependency resolver, but expose them as the requested name through some sort of shim (i.e. if they have src.something.else, and through some method we determine that it can be imported via something.else, it could still have the same unique ID, but be presented as something.else in that new context). I'm not sure what that'd take; we use the module name as the "defining feature" all over the place.

[AlexanderSher]

Name is inherited from IPythonType. Right now we have PythonVariableModule (not the right name, maybe you can suggest a better one), which is created for every referenced module in the scope of the referencing module. So on this level, we can have context-based names. I'll try to separate IPythonModule from IDocument. If that works, there will be no need for the document in RDT to have a name.

[MikhailArkhipov]

db branch introduces QualifiedName to the IPythonType. For module it is just Name. Perhaps it can be used as unique name instead?

[AlexanderSher]

One name isn't enough anyway, because name of the module depends on the referencing module. For example, for the file structure:

root
├─ src
│  ├─ package
│  │  └─ b.py
│  └─ a.py
├─ package
│  └─ b.py
├─ a.py
└─ d.py

and d.py:

import a
import src.a
import package.b
import src.package.b

we should import all four modules if root/src goes after root, and only two modules (from src) if it is added before. So in the second case, b.py can be imported as both package.b and src.package.b.

On the other hand, completions, hover and other analysis-based features operate on top of PythonVariableModule, which isn't shared between analysis instances.

[AlexanderSher]

On the side note, we need to remember that module wins over implicit package:

root
├─ src
│  └─ a.py
└─ a
   └─ b.py

No matter what path goes first - root or root/src - from a import b won't work.

[karthiknadig]

When using this extension https://github.com/microsoft/vscode-python-embedded , people create code.py as the main file for CircuitPython. There is a name collision with code.py in the standard lib.