Relative/partial module path of class due to relative import

[vitsalis]

Relative/partial module path of class due to relative import

[gdrosos]

Thanks for reporting the issue! This might indeed be casued by the special use case of the class, because I tried testing pycg in the aforementioned case where child is a simple function, and I could not reproduce the issue. PyCG could resolve the from library.parent import child import statement and succesfully build the call graph.

[jacksongoode]

Thank you for your prompt response. I was just about to edit this issue. We do a little filtering of the tree based on the parent library and this caused me to miss it.

It actually does have library.other_class.process: [child_classes.child] within the tree but we were expecting the full library path of child, something like ``library.other_class.process: [library.parent.child_classes.child]`. Is this because of the relative import?

I've updated the initial issue to reflect this discovery. The weird thing is that in our library we use relative imports like this everywhere (as most libs do) and in some cases relative imports do include the full path. Not sure why this case is different.

[gdrosos]

This seems to be a weird behaviour indeed.

But still I can't reproduce the issue. When I run the code described above, the namespace is produced corretly and includes the library.parent prefix.
If in the little filtering that you describe you change the location of the file we would expect PyCG to depict a namespace of the new location.

[jacksongoode]

Hmm, well one thing that we've noticed is that modules that appear in the tree as partial paths of the parent library are those that are called from within a submodule like from .stuff import this. While the case that I've abstracted from to propose this issue doesn't result from a relative import, I'm wondering if they are connected somehow.

Here is a clear case:

# stuff/__init__.py

from .file1 import that
from .file2 import this

# stuff/file2.py

from .file1 import that

this():
    something = that()
...

In this case it would show "library.stuff.file1.this": ["file2.that"] rather than library.stuff.file2.that.

[jacksongoode]

Hmm I also find that PyCG does this partial path stuff if it's initiated from the root of the library vs. above it, even when the list of .pys are passed in as absolute paths?

[jacksongoode]

Just want to add a bit of info from correcting the partial module paths that PyCG gives. We found that switching the imports from the file pwdata/pipeline/tests/test_pipeline.py from:

from pwdata.pipeline.memoizer import Memoizer, create_tree

to

from pwdata.pipeline.memoizer.memoize import Memoizer
from pwdata.pipeline.memoizer.cg_tree import create_tree

Would resolve the issues where we only got:

'pwdata.pipeline.tests.test_pipeline.test_cg_tree': ['<builtin>.len',
  'cg_gen.create_tree',
  'memoize.Memoizer']

but wanted to have (and correctly get after the above absolute import fix):

'pwdata.pipeline.tests.test_pipeline.test_cg_tree': ['<builtin>.len',
  'pwdata.pipeline.memoizer.memoize.Memoizer',
  'pwdata.pipeline.memoizer.cg_tree.create_tree']

[jacksongoode]

@gdrosos Just wondering if you were able to see my most recent responses and had any thoughts? If it might make it easier I could make a minimal working example of this in a repo.

[vitsalis]

Closing due to archival of repository.