Say I am building a python project that models bananas, how would I structure it? I usually start with
mkdir bananas
then I code in bananas.py which is file until I start adding README, LICENSE, CONTRIBUTORS, and more and the python files are just lost in meta files. Then I do the same again
mkdir bananas
mv *.py* bananas
in order to have the actual code separated from the meta. Now I have a double, repetitive dir structure,
$ ls /path/to/bananas
README
LICENSE
CONTRIBUTORS
bananas/banana.py
So this ends up in
bananas/bananas/banana.py
This just feels wrong to me. The code I touch most is hidden away too far. Also I hate imports like
from bananas.bananas import Banana
I just want to do
from bananas import Banana
Any thoughts? What am I missing? I quote HGP:
Repetitive paths are confusing for both your tools and your developers. Unnecessary nesting doesn’t help anybody (unless they’re nostalgic for monolithic SVN repos).
Sometimes this is unavoidable. Just look at the datetime module of the standard lib.
datetime.datetime datetime.datetime.today().date()
You can do relative imports. A file in bananas only has to do
from bananas import Banana # or
from .bananas import Banana
Which is recommended anyway to make your module reusable by making it movable m)
Some folks import the module, not the class
from bananas import bananas as bananaModule
bananaModule.banana()
You could also give your project a fancy codename so it becomes:
from fancyish.bananas import bananas as bananaModule
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments