2 ms·
My one massive hate about Python imports, path resolution aside, is that if I want to do from foo.bar import Baz And there's a foo/__init__.py file it gets
by EdwardDiego 4y ago
My one massive hate about Python imports, path resolution aside, is that if I want to do
from foo.bar import Baz
And there's a foo/__init__.py file it gets executed merely from path traversal.
And because of how Django's settings work (import django.settings and all your stuff is magically there), people in my company have gotten into the habit of putting code in settings/__init__.py to do the things they need, like retrieve secrets from AWS.
Which I don't want to have happen when I'm trying to import settings.bla_module to use a type in a unit test.
- mixmastamyk 4y ago> And there's a foo/__init__.py file it gets executed merely from path traversal. Yes, and it needs to—to find the variables there, which may/not be other packages. > how Django's settings work Right. Django is great and popular, and so I think many folks don't realize how downright clunky it is in a number of places. Many parts of it are over-engineered like this one. It has improved over time but some things are set in stone due to history. I'd like their settings redesigned myself. > __init__.py to do the things they need, like retrieve secrets from AWS No, no, no, no... NO! ;-) Imports should only create variables, define functions, and/or alias a package. They should never, ever run lengthy computations or access the network. That's basic software design 101, unfortunately not taught everywhere. I don't see this one as a clear flaw of Python. "Dumb" coding can happen anywhere. I suppose it could prohibit this kind of stuff, but that might prohibit other cool things that might be reasonable in limited situations. It is a "consenting adults" design, with those trade offs.