[allan_s]

> This means that just by importing this module, we're mutating global state somewhere else.

Yes, this !

That's why I hate Django and some flask app the most for, the fact that by importing a module, you're implicitly creating a database connection, and a lot of other magic stuff, which mean that now I can't import a constant defined in said module outside of `python manage.py`

Also as said below in the article, suddenly it's much harder to handle smoothly the "the database is momentary unavailable" (because someone has put the line starting the database connection in the global space of a module somewhere)

I much prefer frameworks/modules for which code is executed only once you invoke their "setup" function

[orf]

Django doesn’t create database connections on import. That would be madness.

It does create an object that can (lazily) connect to the database, so it needs the required database drivers installed. It also needs the required information about _how_ to connect to the database, so it needs the settings loaded.

That's why you need to use `django.setup()` before, to tell it what settings to load. You should never be importing random Django models without this configured, simply because they cannot be used and will not work. We think an exception saying "don't do this, call django.setup()" is less confusing at import time is than "Databases not configured" at runtime. Not that it would even reach that, because you might be using a field from a third party application that needs to be initialized (i.e INSTALLED_APPS configured) or that relies on a configured settings (maybe an encrypted field that needs your SECRET_KEY available).

Stop making it hard, just write a management command. It's super easy.

[nerdponx]

I much prefer frameworks/modules for which code is executed only once you invoke their "setup" function

Django _does_ have a "setup" function. You can't import and use Django database connections outside of a running application without it.

Flask also has a "run" method and does no i/o without it.

[heavenlyblue]

Every time I hear a comment alike parent's, it makes me think how many times a day I actually read a comment in the same fashion, but about something I actually know nothing about.

[diminoten]

What's worse is how many people blindly upvote negativity. It's still somehow cool to shit on things...

[nerdponx]

With credit to the original poster, they might be complaining about the fact that Django is a monolithic framework and you can't really use Django code without spinning up the i/o portion. Which is legitimate criticism, but frankly if that's what you need then you shouldn't be using Django.

[heavenlyblue]

If by I/O you mean web i/o then Django provides a perfectly functional management utility interface accessible through cli.

If, however by i/o you mean the database portion of it then Django works without database configuration, too.

[yen223]

Without calling setup, you cannot import anything that touches Django models, like constants defined in a file that transitively imports a Django model.

In practice, this means that any script that depends indirectly on Django code will incur a lengthy startup cost (from having to call setup()), and will fail to run if there's no database connection, even if the script itself doesn't need the db.

[heavenlyblue]

You can import Django models before calling setup, you will simply not be able to use the database before calling setup.

[tummybug]

I'm not sure about django but flasks Application object has a before_first_request method which takes a function designed to do this type of initialization operations.

[rectangletangle]

I'm a huge fan of Django, but I always felt that this was true. I wish there was more of a push to decouple parts of the framework. Keep the magic, but allow usage without it.