22👍
✅
I usually use imports like this only for one reason
from .foo import bar
from .other import sample
The reason being
If Tomorrow, my module name changes from say ‘test’ to ‘mytest’ then the code does not require a refactoring. The code works without breaking.
Update
All imports starting with a ‘.’ dot, only works within that package.
Cross package imports need require the whole path.
3👍
If test
is another app,
from .other import sample
wont work.
Update:
You can only use relative imports when you’re importing from the same app.
Inside test
app
from .other import sample
will work. But you’ll still need the complete form
from cones.foo import bar
if you import method defined in foo
from test
app.
So answering your question the second way is the correct way.
- Does a library to prevent duplicate form submissions exist for django?
- How does one use a custom widget with a generic UpdateView without having to redefine the entire form?
- Django model subclassing approaches
- Django ORM – confusion about Router.allow_relation()
- How to use bower package manager in Django App?
Source:stackexchange.com