The threat of the incompletely initialized django instance
Hello, since version 1.2, there has been no changes about this issue, which still bothers me: https://code.djangoproject.com/ticket/14916 In summary, the django dev server loads models.py of every INSTALLED_APP, and thus (somehow) ensures proper initialization of models and signals. But in production, web servers do NOT load more than the strict minimum required by the requests they serve, so it opens the door to very subtle and deadly bugs, where the first requests of every new django process might miss a good part of the whole workflow, because miscellaneous "hooks" have not been registered properly. Doesn't this advocate a global import of all installed_apps' models.py, at process setup ? And more generally, people have no idea where to put their django setup code, so there are tons of forum threads and workarounds about this, using mod_wsgi's start script, or code in urls.py/settings.py, or even dedicated on-shot middelwares ( http://www.allbuttonspressed.com/projects/django-autoload). Wouldn't it be worth offering a place, in a project and/or in each django app, which will be called AFTER all models/signals are initialized, but BEFORE the first request is served ? Same behaviour as the "fake middleware" trick, but without its ugliness. thanks in advance, regards, Pascal -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: django.utils.simplejson + stdlib json
After reading that ticket, I'm not sure what Alex and I are disagreeing on. I was suggesting using django.utils.simplejson internally until it's removed, so that at least people could be consistent with django itself. That way, DjangoJSONEncoder would be a simplejson.JSONEncoder (if simplejson is installed) until we remove the shim. I agree w/ deprecating utils.simplejson, and I agree that leaky shims are a fundamental problem, but it does seem to me that the state of play could be better by not using simplejson and json both in the same codebase. DjangoJSONEncoder(json.JSONEncoder) but django.utils.simplejson is simplejson if it's available. Anyway, since we've already deprecated utils.simplejson, since we've already done the damage here, and since doing a release to fix this is probably not going to help that many people (they've either already fixed their backwards-incompat or aren't planning on going to 1.5 any time soon)... maybe I agree we should leave it alone. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: django.utils.simplejson + stdlib json
On 13 avr. 2013, at 22:13, Jeremy Dunck wrote: > After reading that ticket, I'm not sure what Alex and I are > disagreeing on. I was suggesting using django.utils.simplejson > internally until it's removed, so that at least people could be > consistent with django itself. That way, DjangoJSONEncoder would be a > simplejson.JSONEncoder (if simplejson is installed) until we remove > the shim. I see — I hadn't understood that you were proposing this. > Anyway, since we've already deprecated utils.simplejson, since we've > already done the damage here, and since doing a release to fix this is > probably not going to help that many people (they've either already > fixed their backwards-incompat or aren't planning on going to 1.5 any > time soon)... maybe I agree we should leave it alone. Yes, maybe we could have handled this differently, but at this point the cure would be worse than the disease :| -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Request method in urls.py
There's a line in the django URL Dispatcher documentation that is pretty
weird:
The URLconf doesn’t look at the request method. In other words, all request
> methods – POST, GET, HEAD, etc. – will be routed to the same function for
> the same URL.
Well, why? Most modern web frameworks allow you to specify the method in
the routing configuration, Django seems to be an exception in this respect.
It would be extremely easy to implement, and would lead to vastly better
code across new projects, including a simpler way of writing rest style
interfaces:
url('^objects/$', 'views.create_object', methods=['post', 'put'],
name='create_object'),
url('^objects/$', 'views.get_objects', name='list_objects'),
This has come up many times before and been swatted down for various
reasons. One is that it could be implemented with a one-off dispatcher, as
in:
url('^objects/$', create_or_list(list=get_objects, create=create_object),
name='create_or_list_objects')
But this is overly complex for what should be a simple configuration,
forces one to create the same name for the url, and worse, creates a level
of indirection breaking the abstraction up; or in other words you're trying
to do route configuration, why not do it in the place you're already doing
route configuration?
The other argument is that you can do this with Class Based Views. I don't
believe this is a good argument as one would have to utilize Class Based
Views to get this basic functionality. In fact CBV's, only really solve
two common issues, one is the boilerplate inherit in forms, and the other
method routing. But the proposed solution to method routing is simpler and
better.
I will gladly implement the code required for this, but don't wish to do so
if it's going to be quashed, which is why I bring it up here.
Thanks
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: The threat of the incompletely initialized django instance
On Sat, Apr 13, 2013 at 11:53 PM, Pakal wrote: > Hello, > > since version 1.2, there has been no changes about this issue, which still > bothers me: > https://code.djangoproject.com/ticket/14916 > > In summary, the django dev server loads models.py of every INSTALLED_APP, > and thus (somehow) ensures proper initialization of models and signals. > > But in production, web servers do NOT load more than the strict minimum > required by the requests they serve, so it opens the door to very subtle > and deadly bugs, where the first requests of every new django process might > miss a good part of the whole workflow, because miscellaneous "hooks" have > not been registered properly. > Doesn't this advocate a global import of all installed_apps' models.py, at > process setup ? > > And more generally, people have no idea where to put their django setup > code, so there are tons of forum threads and workarounds about this, using > mod_wsgi's start script, or code in urls.py/settings.py, or even > dedicated on-shot middelwares ( > http://www.allbuttonspressed.com/projects/django-autoload). > Wouldn't it be worth offering a place, in a project and/or in each django > app, which will be called AFTER all models/signals are initialized, but > BEFORE the first request is served ? Same behaviour as the "fake > middleware" trick, but without its ugliness. > The reason there hasn't been any update to ticket #14916 is that it has been closed as a duplicate of #3591. Which it is. The ticket title may not make this obvious, but if you read the full ticket history and/or search for #3591 on mailing lists, you'll quickly find mention of an "app refactor". The purpose of the app refactor is to provide a wrapper object that can encompass application-specific configuration -- including things like application startup logic and signal registration -- and to provide a guaranteed and consistent order for startup. There are some draft patches floating around for the app refector; as I understand it, the code was *almost* ready to be merged for 1.5, but there were some last minute concerns, so it was postponed. I don't think there have been any major discussion since then. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: django.utils.simplejson + stdlib json
This problem was gonna have to be eventually sorted through no matter what: the endgame was decided to be "json from the standard library everywhere" which means any projects doing simplejson.dumps([django internals]) would inevitably be affected sooner or later. In theory it's just as distasteful and wrong to perform simplejson.dumps(, cls=json.JSONEncoder) as it is to perform json.dumps(, cls=simplejson.JSONEncoder), however due to the practical concern that for the time being the latter works and the former doesn't, it might have been worth keeping a shim specifically when subclassing JSONEncoder. Of course, there's no guarantee that future releases of simplejson won't make the latter every bit as broken, and eventually Django core is going to require that everyone who uses Django internals use json instead of simplejson anyways, so it's of dubious benefit, and I don't think it's worth re-adding. Best, Alex Ogier On Sat, Apr 13, 2013 at 5:34 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 13 avr. 2013, at 22:13, Jeremy Dunck wrote: > > > After reading that ticket, I'm not sure what Alex and I are > > disagreeing on. I was suggesting using django.utils.simplejson > > internally until it's removed, so that at least people could be > > consistent with django itself. That way, DjangoJSONEncoder would be a > > simplejson.JSONEncoder (if simplejson is installed) until we remove > > the shim. > > I see — I hadn't understood that you were proposing this. > > > Anyway, since we've already deprecated utils.simplejson, since we've > > already done the damage here, and since doing a release to fix this is > > probably not going to help that many people (they've either already > > fixed their backwards-incompat or aren't planning on going to 1.5 any > > time soon)... maybe I agree we should leave it alone. > > > Yes, maybe we could have handled this differently, but at this point the > cure would be worse than the disease :| > > -- > Aymeric. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
