DISQUS

You can specify multiple template directories; TEMPLATE_DIRS is a tuple. But generally the more useful thing to do is take advantage of template loaders, which tell Django where and how to find your template. The most important built-in loader is "django.template.loaders.app_directories.load_template_source", which looks inside each installed application to find templates, thus allowing application to ship their own templates which will be used no matter what.

(also, in my experience, reusing templates across installations tends to be pretty difficult; there's usually not enough overlap in the HTML document structure of different sites to make this sort of thing feasible)

I'm very much not a sysadmin, but I'm going to go out on a limb here and guess it's reverse DNS lookups that are causing the difference between those two rewrite rules.

So. You're setting the P flag on the RewriteRule directive, which means Apache will proxy to the final URL, same as if you'd just set up a ProxyPass directive for it. This means Apache has to be able to construct a valid HTTP request to that URL which, for HTTP 1.1 (which is what everybody does), means it has to know not only the IP address to send the request to, but also the correct hostname to send in the Host: header. When your RewriteRule supplies the hostname, Apache can simply do a (fast, assuming your DNS resolution is set up properly to look locally first) lookup to get the IP address the request goes to. But when your RewriteRule supplies the IP address, Apache must do a (potentially slow, because a lot of folks never set this up properly) reverse DNS lookup to obtain the hostname.

Hence, using the IP address is counterintuitively slower than using the hostname. Or at least that's how I'd guess it plays out; someone more knowledgeable will no doubt drop by and point out where I've gone wrong.

(a similar problem can bite you when setting up virtual hosts, since Apache again needs both pieces of information and it's not always obvious that leaving one out will force Apache to use potentially-slow mechanisms to obtain whatever piece is missing)

And as of a few months back (with the landing of queryset-refactor), there's some (under-the-hood, NOT exposed through any high-level API methods) support for directly dropping a GROUP BY clause into a query.

Jack, if you're going to misrepresent what I said, when my actual words are on the same page, I don't know that I can help you much, either.

Julian, I think you're doing a huge disservice to us all by selectively ignoring things and just repeating an argument over and over when it's been replied to many times already.

There's a very well-defined list of things that describe "ready for the next release". That list is out in public and has been for a while now. And if we rolled a release right this minute, odds are you'd finish QA and upgrades on any deployed projects you have right around the time we'd be ramping up for 1.0 pre-release versions, which would just get you even more upset than you are now.

If you're unwilling to listen, I'm not sure I can do any more to address your concerns.

Well, since you mention #2070 (streaming uploads), consider its history. Most of the early patches fell into one or more of these categories:

* Incomplete, in which case there's no real gain from committing the patch.
* Broken, in which case committing the patch is a regression.
* Out of scope, e.g., coupling server-side behavior to a specific client-side JavaScript widget.

What was needed, and what happened, was for someone to step up and really champion the ticket and put in the necessary work to do it right. This is what Mike Axiak and a couple other folks have done; they've stuck with it through multiple rounds of QA, and understood that at particular times (e.g., the run up to the QS-RF merge) there are other priorities which can put some tickets on the back burner. As it stands, that ticket is on the (publicly-published) list of stuff to get into 1.0.

Once you start digging in the ticket system and associated discussions, you find a lot of things like this; committing database-internals work before QS-RF, for example, would have been a bad idea since the code would have had to be rewritten almost immediately. Now that it's merged and is shaking out, a good task for someone during a sprint would be to go through such tickets and get them ready for commit.

And note that none of this is hopeless perfectionism; in fact, much of it is extremely pragmatic. Similarly, the next release will be 1.0, not out of idealism but out of practicality

I'm also somewhat confused at the claim about delegation; for example, every time someone volunteered to do in-trunk work on MS SQL, they eventually dropped off and left it dead. Dead code is bad, so until someone manages to complete the work separately and get traction for it, that's not going to go back in trunk. The fact that there are competing implementations doesn't change this at all, so far as I can tell.

I also wonder what good, precisely, would come out of, say, arbitrarily stamping a 0.97 release right now. It would be interpreted as "here's a release to shut you up" rather than "Django's ready for a release and here it is", and that would be far worse. At any rate, since the biggest problem seems to be a perception that it's hard to figure out what's going on (and since even highly-visible public discussions don't seem to help), Jacob will be posting some stuff soon with excruciatingly obsessive levels of detail.

The default views are all documented right there on that page you linked, including the arguments they accept, the template names they expect and the variables they provide to the context. I'm not sure how much easier to use you can get from the docs, unless they come to your house and write your app for you.

The book covers implementation of a sign-up view, but doesn't go into anything else -- it's not an exhaustive reference, like the djangoproject.com docs are.

The relevant views have been in Django since the very first public release.

The fact that they use oldforms is annoying, but tons of stuff in Django still uses oldforms; that's why it's still described as being in transition.

And arrangement *does* make a difference; one of the great things about Python providing easy namespaces is that it's simple to arrange things in a way that makes sense based on what they do. You don't have to do any work to get a useful namespace, and you aren't bound by "one public thing per file" restrictions as in some languages. So why not take advantage of it to the fullest? You'll notice that django.contrib.auth puts all its views into one file and names them descriptively -- there's no logical reason to spread them out over a bunch of files, so it doesn't.

Paul, django.contrib.auth already *has* login, logout, password recovery, etc., built in. There's no need to write code for these, just point some URLs at the already-provided views that ship in Django. Hence django-registration does that (look at the URLConf it supplies).

It doesn't provide templates because there's no such thing as a set of truly portable default templates -- I tried that once upon a time and learned the hard way. And if you want a captcha in the form, take a look at the documentation -- the registration form is designed to be subclassed for additional functionality (and provides several example subclasses showing how to do that).

And I don't see how, for example, a "login" and a "logout" view both deserve their own complete files -- they're providing two parts of a higher-level functionality, so why *aren't* they in the same file?

Well, django.contrib.auth already provides login, logout, password change and password recovery, along with the necessary forms. For signup there's always this (released publicly about a year ago, uses newforms, provides a full, extensible solution):

http://code.google.com/p/django-registration/


As for idiomatic: one glaring thing is the way the views are strewn out over several files, and often given non-descript names like "run". A more natural solution (for Django, as well as for Python in general) would be a single file with a descriptive name, containing several auth-related view functions (again, each with descriptive names) and, possibly, a separate file for the forms.

I can't help wondering why you reimplemented so many things that were already in django.contrib.auth (and reimplemented them in a fairly non-idiomatic way); is this just really ancient legacy code?

Maybe I'm missing something, but how does this differ from the built-in "truncate" and "urlizetrunc" filters?