>I was going through magic removal wiki page, and encountered this, I think
>there is still some magic left in the Custom managers, and multiple
>managerssection. I have a following objections:
It's maybe not perfect, but a very good start. No one prevents later
refinements - we just need something useable and workable for 1.0.
> - finding the default manager based on the order in which they are
> defined
Uhm. Wasn't there a default_manager=True parameter or something like
that, if you want to need to specify the default manager?
> - manager instance magically contains self.model
In what way is that magic? Looks like a simple attribute to me. Manager
instances are created within the namespace of the class, so it's not
really magic happening. Every method "magically" contains a pointer to
the class it was defined in. Every class in python contains "magically"
a link to the module it is defined in. Every module contains
"magically" the file name it was loaded from (if it was loaded from a
file). Sorry, but that's something that is done throughout all of
Python.
>I have the following suggestion:
>Put each model in a seperate module [in the myproject.myapp.modelsdirectory].
Ugh. No. Please. Don't. Do. That. A big -infinity on that.
Sorry, but a) it doesn't solve any of the above non-problems and b)
adds load of boilerplate. The current structure of a simple Django
application is quite nice: models.py, views.py and maybe a few
templates, that's all you really need. I would even opt to move the
templatetags/xxx.py into a templatetags.py, but that might add some
"magic" to the taglib loading stuff, because you would do {% load app
%} to get app/templatetags.py loaded. But the gist of this: have as few
files as possible _required_ by the framework.
Nobody prevents you from doing models/__init__.py and loading all your
model snippets in there - but I am really strong objected against the
framework _requiring_ such bloat. So if your app really needs
structuring models into different files, you already can do it - and
you can do it later, because the change from models.py to
models/__init__.py is non-intrusive to your application code.
Actually I would even go so far to say that when a _single_app_ in your
Django project has so much models that it _requires_ spreading over
multiple model files, you might even have a problem with your design -
because you would be much better with multiple _smaller_ applications
with less models.
Yes, I understand that sometimes you don't have a choice - for example
with legacy models. But it would be rather silly for a framework to put
up requirements that go beyond what usual apps will need, just because
of some edge cases.
So, again, a big fat -1 on requiring multiple model files.
bye, Georg
