How to avoid name conflicts in a modular Python system?

In my Django project, I have an application called profile that basically contains my profile.models.UserProfile class for more information about User objects (might seem familiar to Django people). Now I put some initialization code in profile/__init__.py (some signals) and ran into a problem: Django tells me that a table named hotshot_profile not found.

After literal hours of searching, I traced the problem back to importing the order. Running python -v manage.py test I found the following:

 import nose.plugins.prof # precompiled from /home/rassie/.virtualenvs/myproject/lib/python2.6/site-packages/nose/plugins/prof.pyc import hotshot # directory /usr/lib64/python2.6/hotshot import hotshot # precompiled from /usr/lib64/python2.6/hotshot/__init__.pyc dlopen("/home/rassie/.virtualenvs/myproject/lib64/python2.6/lib-dynload/_hotshot.so", 2); import _hotshot # dynamically loaded from /home/rassie/.virtualenvs/myproject/lib64/python2.6/lib-dynload/_hotshot.so import hotshot.stats # from /usr/lib64/python2.6/hotshot/stats.py import profile # directory /home/rassie/MyProject/apps/profile import profile # precompiled from /home/rassie/MyProject/apps/profile/__init__.pyc 

So, my Nose runner imports nose.plugins.prof (even if this plugin is turned off), imports a hotshot that tries to import profile . However, profile imported from my project , while it must be imported from the Python system.

Obviously, my own profile module collides with the system profile module. I obviously cannot exclude every module name that comes with Python from my own programming. So the question is, where am I going from here? Do I need to create myproject namespace for all my applications? Will Django work with this?

PS: The hotshot_profile table hotshot_profile seems to be related to another not yet fully analyzed name collision with the pybb profile class, which I also use in my project. But this is out of the scope of this issue.

+6
source share
1 answer

You should not import your own modules in the form of import mymodule (relative import). Instead, you should always use import myproject.mymodule (absolute import). This avoids all name conflicts.

+5
source

Source: https://habr.com/ru/post/901730/


All Articles