Relative/partial module path of class due to relative import

[jacksongoode]

Hi @vitsalis @gdrosos happy to see the project has seen some cleanup. My team has a unique use-case where our classes are called as if they're functions (with methods called from __new__). That said, we don't think this should impact the way PyCG interpret the call path.

In this case we import a class like:

from library.parent import child

Where the ls of library/parent/ looks like [ child_classes.py __init__.py ] and the child_classes.py contains the class class child():. The __init__.py file has the statement from .child_classes import child.

What doesn't work

When I attempt to import this class child and use it in my other class other_class like:

# called_file.py
from library.parent import child

class other_class():
    process():
        stuff = child()
# ...

PyCG finds that other_class.process depends on child_classes.child. Where the call graph is...

library.other_class.process: [..., child_classes.child, ...]
````.
Here we would instead **expect the full module path** 

library.other_class.process: [..., library.parent.child_classes.child, ...]

## What does work

However when I change the import to use the full path.

```py
from library.parent.child_classes import child

PyCG does create a tree that reflects the full module path library.parent.child_classes.child for library.other_class.process.

---

Question: Wondering if this is expected or if there is something we should keep in mind in our file structure or init files?

[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.