devdev2050

Got an instant reply from Adrian Holovaty over on the Django team in the comments to the last post — see what I said about attitude? Fuckin awesome, I love the internet — so I tried to reply as promptly:

* Doing magic things based on the name of the database field is NOT a good idea, in my opinion. One of the things that I like about Python so much is the mentality that “Explicit is better than implicit.” We’ve had a number of cases in our usage of Django where we explicitly *don’t* want to have a date field in “list_filter”. If Django automatically put date fields in “list_filter”, I’d consider that a design smell, because Django would have to provide a way of overriding that behavior — say, a “list_filter_ignore” setting — which would be quite ugly.

Typically, the way it would work is as a default. If no list\filter is set, build the default list, if a list\filter is set use that. It adds the uncommon case that if you don’t want any list_filter to display you would set the value to None.

Regarding the “explicit is better than implicit” mentality, to me that refers to coding constructs like Perl’s tendency to have things like if /perl/ { print; } for readable code, and I would argue that a framework’s goal is to provide you with solutions to the most common problems in the least number steps while still providing the ability to choose a less common path. When I add the META subclass and add the admin property to it, I am explicitly stating that I would like to be able to edit the model in the admin interface, but Django implicitly assumes I would like to edit all the fields because that is the most common case. Should I care to, I can use the fields property to remove fields or modify the order, but nine times out of ten I probably won’t care that they are all there or what order they are in until I am handing it off to a client who needs specific hand-holding.

I want to be given the most useful tool for what I am doing. If I am doing UI optimization, I’ll need to be able to edit the order of the fields, but if I am not I probably won’t care. If I have a set of data with some common features that can be filtered on, start off by providing those to me and let me get rid of them if I need or want to. A date filter is easy and common, regardless of whether you sometimes don’t want it the overwhelmingly common case is that it is helpful.

* I’d love to see your solution of not having to add projects to the global search path, when you come up with it.

Just a proof of concept, but check out the mods done to core/meta/\\init\\.py and conf/settings.py in the svn. Basically just uses the imp module.

* Regarding templates: Views are decoupled from the template system. That’s a feature. It means you can use whatever template system you want. And it means you don’t have to *use* a template system — if, say, you’re generating non-textual content. For example, we’ve used Django to output PDFs, XML, ZIP files, etc. That said, I’m interested in streamlining the way templates are loaded. Ideas are totally welcome.

Will have to get back to you on this one, have actual work to do today :p

* Regarding django-admin.py: Setting an environment variable is an issue for you? It’s generally something you set up once (in a single command) and don’t have to worry about again. I like your idea of deducing the settings directory based on the current working directory, but we’d just have to figure out which takes precedence: the environment variable, or the working directory. I see positives and negatives to both.

Yes, I could set it up once if I were working on a single project, if I am working on multiple it runs quickly out of control (yes, I realize that the global namespacing of the projects makes multiple projects able to share apps quite a bit easier, but it could perhaps be done via absolute path as well -shrug- ). Using an environment variable is simply an inelegant way of solving the issue of a global configuration continuity. The architecture is elegant enough as it is that a few simple calls can make it relative to the current path at any time. Regarding which takes precendence, my suggestion would be give the command-line argument highest priority, then current directory and ditch environment variables altogether.

* Finally, please do get involved with Django on the mailing list. You’ll find that we’re incredibly open to changing things and making it as kick-ass of a product as possible. We just changed the model syntax — one of the fundamental parts of the system, for crying out loud — based on user feedback. I could certainly see us integrating your patch(es), for instance, after a brief bit of discussion. We went public with the source code before a first official release in order to get valuable feedback on it — feedback like yours. I appreciate it. And you should understand that the ink is far from dry on this baby.

I’ll sign up right away. Don’t take my review to imply that I don’t like the system, I really think it is quite good. And I did notice the model change, part of the reason why I mentioned attitude up there, the whole Django project seemed to have an uncommonly high sense of doing something well so I hope to have enough time to get involved (especially considering how much code I just audited to make these little examples ;) ).

See you on the mailing list.

Technorati Tags: code, django, frameworks, python