4 ms·

Django has hidden thread locals, Flask makes them explicit, so a lot less magic.

orf 9y ago
I was interested so I had a look at the source. There is a single use of a threading.local object in the RegexResolver. There are 5 other usages in total, one in the live reloader, two in the tests and two in GeoDjango. Explicit magic is still magic, and Django contains surprisingly little magic of any type overall, including thread locals.
- Walkman 9y ago
  what about the ORM? https://github.com/django/django/blob/master/django/db/utils.py https://github.com/django/django/blob/master/django/db/utils...
  - orf 9y ago
    Good point, I was only searching for explicit "threading.local" references. So there are 4 more or so. Django uses thread locals in some places where it's needed, but that's beside the point though. It doesn't put thread local objects at the core of its API. Passing an explicit request (real or fake) into functions is much more testable and generally better than relying on a 'request' global, IMO. Same with all the other app globals [1]. A better, more specific argument about Django's use of magic is the models. It uses some dark black magic voodo metaclasses to implement those. Apart from that, the forms, admin, app registry, urls, views is pretty straightforward. But hey, it's personal preference. I like flask mostly: for some situations it is amazing. 1. http://flask.pocoo.org/docs/0.12/api/#application-globals http://flask.pocoo.org/docs/0.12/api/#application-globals
    - Walkman 9y ago
      About testing: it's not actually True. Flask is easy to test. Also, Flask makes everything explicit which is less surprising than hidden thread locals. Also, putting things into thread locals somewhere makes explicit request objects totally pointless, because you still depend on threads and can't use Django in an async manner. So it's not a valid good technical argument either. You might like that better, but that's just a subjective opinion.

orf 9y ago

I was interested so I had a look at the source. There is a single use of a threading.local object in the RegexResolver. There are 5 other usages in total, one in the live reloader, two in the tests and two in GeoDjango. Explicit magic is still magic, and Django contains surprisingly little magic of any type overall, including thread locals.

Walkman 9y ago
what about the ORM? https://github.com/django/django/blob/master/django/db/utils.py https://github.com/django/django/blob/master/django/db/utils...
- orf 9y ago
  Good point, I was only searching for explicit "threading.local" references. So there are 4 more or so. Django uses thread locals in some places where it's needed, but that's beside the point though. It doesn't put thread local objects at the core of its API. Passing an explicit request (real or fake) into functions is much more testable and generally better than relying on a 'request' global, IMO. Same with all the other app globals [1]. A better, more specific argument about Django's use of magic is the models. It uses some dark black magic voodo metaclasses to implement those. Apart from that, the forms, admin, app registry, urls, views is pretty straightforward. But hey, it's personal preference. I like flask mostly: for some situations it is amazing. 1. http://flask.pocoo.org/docs/0.12/api/#application-globals http://flask.pocoo.org/docs/0.12/api/#application-globals
  - Walkman 9y ago
    About testing: it's not actually True. Flask is easy to test. Also, Flask makes everything explicit which is less surprising than hidden thread locals. Also, putting things into thread locals somewhere makes explicit request objects totally pointless, because you still depend on threads and can't use Django in an async manner. So it's not a valid good technical argument either. You might like that better, but that's just a subjective opinion.