> I don't understand how avoiding the settings.py mechanism will produce > *more* flexibility.
Bad choice of words on my part, sorry. Of course code is always more flexible than static data. The two key bits of required 'flexibility' I didn't have out of the box (and were difficult to hack and get working) are: 1. App level settings that are mutually exclusive (one app needs settings different from another - this happens a lot). 2. Setting definitions that aren't tied in timing and scope terms to Python's import process (I've seen this interact badly with start-up code, for example). And it would be cool to have a level of indirection so that settings could be guaranteed to be dynamic (some are, some aren't, those that are often need monkey-patch style hacks to change). And tools for debugging where settings for a failed request are defined. And a security layer around some settings. And fields and fields of other ponies. Seriously though, I don't think the settings.py approach is broken. It makes sense, makes getting from nothing to runnable code a breeze, is logical for small deployments, and has bags of flexibility for most use-cases. I'm happy adjusting it in my projects. I've never deployed or seen deployed a system that used settings.py in anything like its default version, but the replacements aren't standard enough to be an alternative default; every client has different technical, management and internal politics constraints. My comments were meant in the spirit of Jacob's. Just FYIs for a particular niche of users. I should also say that most of the developers I work with do love working with Django. So their criticisms have to be taken against a background of strong positivity.
-- 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.
