On 12/27/05, Dody Suria Wijaya <[EMAIL PROTECTED]> wrote: > > 2. why create a "virtual" module at runtime for each model (the > plural+lowercase of model class name)? > I suppose binding the methods (get_XXX) to the model's class (class > method) is more easily understood, and can be implemented in terms of an > inheritance/mixin. That way, I could hold on to 1 thing to do everything > with the model.
This is currently being fixed in the magic-removal branch. There are a few recent threads on the django-dev mailing list discussing the changes. > 3. refering to #2, why magically bind the module to > django.models.filename module namespace, instead of letting it be > importable naturally according to file system (ie: from > myproject.app.model.poll import Poll) This is also changing in the magic-removal branch. > 4. not related to model, why use only environment variable > (DJANGO_SETTINGS_MODULE) to inform django the location of settings.py? > isn't it more intuitive if django can assume that the file _might_ be in > the current directory (or in this case, python path)? this can get rid > of extraneous configuration hassle of setting DJANGO_SETTINGS_MODULE in > httpd.conf (mod_python) or in shell (django-admin.py runserver) In newer (svn trunk, not 0.9) versions of django, django-admin.py startproject create a manage.py file for your project that basically provides access to all the other django-admin.py commands. manage.py is project-specific and doesn't require DJANGO_SETTINGS_MODULE. Joseph
