You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For instance, python's os.path is actually either posixpath or ntpath. Either way os.path.basename doesn't exist, since os.path shadows another module.
We need something that knows if you can't find the full symbol name and if part of the symbol's qualified name is a shadows import to check that shadows import for the symbol.
I don't think the code has the data structure to support this, since the symbol table is not capable of de-referencing. This means that the code would need to do the de-referencing ahead of time, but this could result in massive duplication of data, since now every module that is imported will have it's contents unloaded. This could be quite the a lot of symbols if someone did this with numpy, for instance. Or we need to make a new table that helps to dereference the symbols, providing mappings for all potential de-references. The downside of this approach is that we wouldn't have a way to tag a de-reference entry to a particular version of the package, since some versions may not have the needed pointers.
For instance, python's
os.path
is actually eitherposixpath
orntpath
. Either wayos.path.basename
doesn't exist, sinceos.path
shadows another module.We need something that knows if you can't find the full symbol name and if part of the symbol's qualified name is a shadows import to check that shadows import for the symbol.
Eg.
os.path.basename
->os.path
->posixpath
->posixpath.basename
I don't think the code has the data structure to support this, since the symbol table is not capable of de-referencing. This means that the code would need to do the de-referencing ahead of time, but this could result in massive duplication of data, since now every module that is imported will have it's contents unloaded. This could be quite the a lot of symbols if someone did this with numpy, for instance. Or we need to make a new table that helps to dereference the symbols, providing mappings for all potential de-references. The downside of this approach is that we wouldn't have a way to tag a de-reference entry to a particular version of the package, since some versions may not have the needed pointers.
@dacamo76 what do you think?
The text was updated successfully, but these errors were encountered: