Namespace issue with `DesignUnit`

[domWalters]

In __init__.py, the DesignUnit class is imported from the DesignUnit file and retains its name.

As a result, it overwrites the DesignUnit module.

So, the following causes an error:

import pyVHDLModel

class LibraryClause(pyVHDLModel.DesignUnit.LibraryClause):
    ...

    class LibraryClause(pyVHDLModel.DesignUnit.LibraryClause):
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
E   AttributeError: type object 'DesignUnit' has no attribute 'LibraryClause'

This is because type(pyVHDLModel.DesignUnit) == <class DesignUnit>.

You have to do a from ... import to avoid this issue:

from pyVHDLModel.DesignUnit import LibraryClause as BaseLibraryClause

class LibraryClause(BaseLibraryClause):
    ...

[Paebbels]

To my knowledge, using import <package> or import <package>.<module> is discouraged.
The from ... import ... form should be used.

If I run into similar problems I use:

from pyVHDLModel.DesignUnit import UseClause as VHDLModel_UseClause

I looked it up in pyGHDL.dom.

[domWalters]

Whilst I agree that that is a functional workaround, I think the way that the class is primarily referred to in the documentation should work to import it:

https://vhdl.github.io/pyVHDLModel/pyVHDLModel/pyVHDLModel.DesignUnit.html#pyVHDLModel.DesignUnit.LibraryClause

The documentation refers to it as pyVHDLModel.DesignUnit.LibraryClause, so I'd expect the following to work:

from pyVHDLModel.DesignUnit import LibraryClause

But it doesn't due to the DesignUnit class name collision.

And the python error is very unhelpful.

---

The namespace collision is happening because the __init__ file is importing it:

https://github.com/VHDL/pyVHDLModel/blob/main/pyVHDLModel/__init__.py#L79

from pyVHDLModel.DesignUnit import DesignUnit, ...

That then implicitly exports it at that level in the hierarchy.

This means that although the DesignUnit class is referred to as pyVHDLModel.DesignUnit.DesignUnit in the docs, it is also available as pyVHDLModel.DesignUnit, which was almost certainly not intentional. This will be true for every single thing that is imported in __init__.py.

Additionally, you're only importing it to implement some of the other functionality that is defined in __init__. Those definitions could be in another module and this problem would go away.

Some linters will explicitly tell you to do this, e.g. ruff.

If such a refactor were performed carefully, it would not be a breaking change (based on what the docs say is available) but would fix this issue.

[domWalters]

I'd be happy to make a proposal PR for such a refactor.