Looks like a fantastic start. Some style stuff to fix, and a couple ideas regarding mimetype matching.

What about the renderer for the .txt file you show in the screenshot? Seems like a good one to include too.

No blank line. Djblets is third-party in Review Board's perspective.

First line, immediately after the """, must be a one-line summary. Then a blank line, then a description of the class.

It'd be nice to document these functions.

Blank line between these.

Interesting. Never knew about __subclasses__.

This will, I assume, only return direct subclasses and not subclasses of subclasses, but I guess in this case we're likely to recurse?

My one concern is how we deal with priorities. If two things claim to match, one should win, but which? Some might be more specific.

For example, a handler specifically for text/* and one for text/html should prefer the second for HTML files.

We can figure this out by having a way of scoring the match by assigning one point for each of the following:

* Mimetype matches in some form (exactly, or through wildcards, or by stripping out the +foo, or by being a subset of the mimetype -- text/plain vs text/html)
* Left-hand side of the "/" matches exactly.
* Right-hand side matches (possibly by stripping out the stuff after "+", if it exists, or being a mimetype that is a subset of another)
* Right-hand side matches exactly (including the "+foo")

So.. something like that.

The points are only returned if the mimetype is compatible. Through the scoring, we can pick one handler over another based on how confident that handler is that it knows better what the mimetype is.

By consolidating this logic in MimetypeHandler, the subclasses could by default just have a list of mimetypes they support instead of overriding handles(). Of course, they could always override that, but it keeps the basic case simple.

Blank line between these.

Blank line.

(I prefer blank lines between blocks (if statements, loops, etc.) and other code on the same level.)

This should be using the static() function. It's a templatetag, but you can import it and use it like a function. If you grep around the codebase, you'll see examples.

Also, you can get rid of MEDIA_SERIAL now.

Same comment here about one-line summary.

Is this the right default? I'm not sure we want to default every MimetypeHandler to matching. Maybe keep this False here, and have a GenericMimetypeHandler subclass that sets this to True.

Always have a period after sentences in docs. These will eventually end up on webpages.

When you only have one line, the """ should be right up against both sides of the text.

What's the point of the function? Can this roll into get_thumbnail below? Or is it for subclasses?

If it's for subclasses, it shouldn't have a _.

Yeah, should be fine. Make this a @property though.

It's nice to keep these roughly alphabetical.

I believe border, margin, and padding can be "0" instead of "0px".

This is looking great. The remaining things are very minor, but this will be going in soon :)

This is a classmethod, so 'self' is wrong. It should be 'cls'.

Same about cls vs. self.

The % should be aligned with the '<img

Parameters need to align.

And, hmm, I think you could get the full path from the FileField. Not sure you need to os.path.join. There's a method injected into the model, I believe.

with: is only in Python 2.6. Just use standard:

f = open(...)
...
f.close()

Are you sure height - 1 is correct? range is inclusive (so a height of 3 will produce [0, 1, 2], or in your case, [0, 1]).

The % preview should be aligned with the parameters.

Weird convention. Shouldn't use _, and should spell out Mimetype.

Same with all other classes here.

I know this was forever ago now, but we're finally back in feature mode for the release. This is awesome, and I'm just about to commit it. Thanks for all your work on this!