On Oct 13, 3:12 pm, Benjamin Slavin <benjamin.sla...@gmail.com> wrote: > On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > I know it was sloppy of me to call it "INSTALLED_APPS loading" as that > > happens in db/models/loading.py - I thought it would be clear from my > > saying I was talking about calling from Settings.__init__(). > > Ok... I see what you're saying. I've always viewed that block as > simple expanding the wildcard entries in INSTALLED_APPS and didn't get > that you were referring to it. My apologies for the misunderstanding > there.
I *was* a bit sloppy calling it "loading". > My concern -- borne from my own work to solve this problem -- is that > it gets very tricky to simply apply a set of coding practices to solve > the problem. I know that saying "you can't import anything that might > import a model" was difficult for my team. We got it to work, but it > did take a good bit of effort to get things working. > [snip] > We are mostly aligned. The problem, again, comes from the risk of > spurious imports. Maybe we were doing something wrong when we tried to > solve this previously... but I can tell you that the import problem > was a real pain for us.. even when we were trying to be careful. I've felt that pain myself :-( > So, I do understand the direction you're headed. My concern (from > experience) is that it's not as simple as the restrictions on > settings.py. In settings.py you have a single file to worry about and, > as I said before, we don't tend to see many imports there because it's > configuration not logic. [snip] > This is actually a different problem. It's a circular import: > django/db/__init__.py does an import of settings... which imports your > settings.py... which imports CursorDebugWrapper (which passes through > django/db/__init__.py)... and so on... so you're going to get an > ImportError. I understand. The point I was trying to make was, doing many imports in settings.py leads to headaches, not just premature imports of models. > However, I'm actually really glad you used this example. It's helped > me realized that the circular import problem actually means that we > can't explicitly or accidentally import our settings either... which > means even Simon's code would stop working. [snip] > I think that we need to keep settings as a discrete piece of > functionality -- establishing configuration. Yes, it shouldn't become a dumping ground for stuff, but it seems the obvious place. > It looks like I may actually be able to put a bit of time toward a new > implementation for this, so I'll keep the list posted. Great! Regards, Vinay Sajip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~----------~----~----~----~------~----~------~--~---
