The mimetypes module does not respond with "text/csv" for files that end in ".csv", and I think it should  :)  For goodness sake, "text/tab-delimited-values" is in there as ".tsv", and that seems much less used (to me).

Yes, but text/tab-delimited-values/.tsv is older.  .tsv dates from the days of Gopher, but text/csv was formalized only in October of 2005.  Presumably nobody has asked for it before, for some odd reason.

Now we get to debate again whether updating mimetypes with a registered type can be considered a bug fix.  We've gone both ways in the past, as far as I can tell.  This one has the advantage of actually having a formal IANA registration, unlike the last couple.

I would argue the embedded mime-types dictionary should at least mirror current IANA assignments, which are already present in up-to-date Unix systems:

>>> mimetypes.guess_type("foo.csv")
('text/csv', None)

So not having text/csv is IMHO a bug.
Also it would be nice if there were an easy way to keep the mime-types dictionary up-to-date wrt. a system's mime-types file.

As far as I know having it mirror the IANA registry is the intent (there's a comment in the module that can be read as implying that).  So I'd be inclined to treat this one as a bug and fix it in 2.7 and 3.2 as well as 3.3.

I'm not sure what you mean by your final comment, since by default the system mime types are read on both Unix and Windows and merged with the built in table.

> I'm not sure what you mean by your final comment, since by default the
> system mime types are read on both Unix and Windows and merged with
> the built in table.

I mean to have our built-in table mirror a recent Unix system's
mime-types table. There could be a special switch to mimetypes.py, which
would output the Python code of a dict mirroring /etc/mime.types (or
"/etc/mime.types" + the current built-in table) when run. Then it would
be easy to integrate the changes back into the code.

Ah, analagous to the way keyword.py regenerates its embedded table based on the actual python grammar?  Yes, that would be nice.

I’ve been one to argue that additions to the mimetypes registry are clearly new features.  Now if two senior devs like you think otherwise, I’m reconsidering.  These additions can’t possibly break code, can they?  So I can agree with a viewpoint that mimetypes should match what the IANA publishes and that adding missing types is a bugfix.  (It’s less disturbing than updating HTMLParser for example, and I agree with that.)  Georg’s inclusion of a registry addition for IIRC 3.2.2 would also indicate RM support for this viewpoint.

About Antoine’s remark: mimetypes already reads mime.types files, so even if our internal registry is not up-to-date the module should know about all types present in /etc/mime.types.

> About Antoine’s remark: mimetypes already reads mime.types files, so
> even if our internal registry is not up-to-date the module should know
> about all types present in /etc/mime.types.

The point was about systems which don't have a /etc/mime.types
(Windows).

On Windows we do (now) read from the registry as well.  My guess is there are a lot more Windows systems out there with outdated registries then there are unix systems with outdated /etc/mime files, though.

One solution would be to update our mimetypes file just before a new version, and then leave it until the next, just as we update unicodedata to current unicode and then leave it alone for bugfix releases. Rather than the entire IANA file, which has a lot of useless stuff, we might update from the most recent *nix files (assuming that they have less than 'everything').

Patch against 2.7 to add csv to the internal list. It is popular enough as a format, that it should work even if the system mime files are stale.