Hi Russell, On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
> At this point, I'm calling for feedback, particularly on the following: > > * logging config as the last stage of settings loading. Is this the > right place? Can anyone think of a better place? In the context of running a Django app, this means it will definitely get called before the first request is dispatched, due to the need to find the URLconf. From the context of command line apps, it is less predictable in general, but I guess the command line app has to be responsible for ensuring that logging gets set up first. Anyway, this seems good to me, and I can't think of a better place. For the probably rare case of putting logging calls in your settings.py (like Hanne Moa does), there is nothing to stop you setting up logging yourself inside settings.py, which Hanne must presumably do already. The only problem is that logging could be set up twice. For this case, I guess we could support some convention like 'LOGGING_CONFIG = None' to stop Django configuring logging altogether and add a note in the docs. This might also be useful for the command line app situation. > * The default logging configuration. Have I got the > propagate/override options right for sensible defaults (both in global > and new-project settings)? I don't really have much experience with the logging module, but they seemed sensible to me. > * The logging calls that have been introduced. Is this too much or > too little? I'd rather err on the side of caution here (we can always > add extra logging later), but I'd like suggestions on anything else > people think should be logged. Also, are they logged at the right > level (e.g., is a 404 a warning?). These all look good to me, and cover the obvious cases. Warnings for 4XX codes seems good, since they could be a sign of something "going wrong" - dead links or some kind of attack - while not necessarily being an actual problem in the code, and it is useful to filter that category. > * The startup.py convention (and implementation). Is this necessary? > Does it address (or not address) any other prominent "on startup" use > cases? There's also a crossover here with Arthur's GSoC work; is the > startup code sufficiently important that we need it anyway, or can we > defer until the app refactor lands? I'm not sure what use cases this specifically targets. It seems that it depends on 'AppCache._populate' being called. From what I can tell, that isn't guaranteed to be called until some database query is made, or it is called by an app like the admin. Without the admin I can create an app that never populates AppCache but can serve responses. I don't see anything that depends on this startup proposal though, so I'd propose dropping that part until the other options have been discussed. Regards, Luke -- "Christ Jesus came in to the world to save sinners" (1 Timothy 1:15) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
