Instead of returning the first in the list of
extensions it should return the most reasonable . here:
to have a *.txt on disk after saveing?

Logged In: YES 
user_id=469548

How would you suggest finding out what the most reasonable
extension for a mime type is?

Logged In: YES 
user_id=972995

in mimetypes.py there is already a

common_types = {
    '.jpg' : 'image/jpg',
...

.txt could be added,
mayby guess_extension should first reverse-take it out of
there, not random ...?

background: my intent was to save MIME attachment as
(startable) temporary file. yet got wonderful .ksh's for
textfiles, and had to fumble ...

 

Logged In: YES 
user_id=469548

common_types is for adding some non-standard types, not for
determining which extension is most reasonable. I'll be
happy to look at a decent patch, but I'm moving this to
feature request until then.

Logged In: YES 
user_id=341410

While I agree with the original poster that returning '.txt'
is preferable to the others in the list returned by
mimetypes.guess_all_extensions() at least 9 times out of 10,
being able to prioritize all of the types is not necessarily
the easiest thing to do for all of the possible returned lists.

Is using a custom comparison function along with the list
returned by guess_all_extensions() sufficient?

Confirmed on trunk.

I'll close this in a couple of weeks unless someone wants it kept open.

I think you are closing too aggressively.


Python 3.2a0 (py3k:81783, Jun  6 2010, 16:07:26) 
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_extension('text/plain')
'.ksh'
>>>

While I agree that getting .ksh is an unfortunate guess, I am not sure how you can guess in the face of many options (especially when the those options are parsed out of a mimetypes file or the windows registry). 

Perhaps there should be a "resonable_defaults" map that is checked first for very basic types where there are multiple extensions for a type?

6 years old and still not fixed?

http://www.stdicon.com/mimetype/text/plain

Please return txt

ksh is a text/plain to, all this extension are text/plain:
'.ksh', '.pl', '.bat', '.h', '.c', '.txt', '.asc', '.text', '.pot', '.brf'.
The problem is: the code return the first of list:
return extensions[0]
So, I add one boolean parameter in method guess_extension called all_exts. Putting True in this parameter the method returns a tuple with all possible extensions.

I hope helped

Rafael,

There is already a method which returns all the extensions. What is required is a flag (or separate dict) which provides a canonical extension. The questions is whether it is sufficient to rely on the default provided mimetypes for the default in the face of mimetypes read out of the mimetypes files or windows registry.

I don't see a way to fix the bug, without also providing an API to "pick the winner" for those cases that are not provided in the default list.

The proposed patch does not solve the issue.  In the current API, there is no way to do it, so this bug requires a new feature.  I think it would involve a new dict, like preferred_extensions, which would be seeded with default values, like .jpg for image/jpeg and .txt for text/plain, and a few functions/methods to query the dict or add items.

I'm running into a similar issue with this function. My bug is that get_type('foo.png') returns image/x-png. This occurs on windows because there are mappings to both image/png and image/x-png in the registry (as there should be, since that key is actually a reverse mapping) and the code simply picks the first key that it enumerates over. This issue strikes in both directions.

Chris and others bring up a valid issue: how to decide what the winning result is?

I think the answer is pretty clear - you use the common_types mapping already in the file and expand it as appropriate. If the mimetype can't be found, only then do you go to the windows registry. The behavior on Linux is even stranger to me (now we'll dig through an arbitrary list of files that might contain MIME info or may have completely irrelevant data) but it's a pragmatic solution.

If someone needs to customize what guess_type returns, they can simply wrap the guess_type function in their own code or monkey patch if they don't have access to the source they're running. Changing such a mime type is a really advanced and unusual operation. If that's unacceptable, the code can provide a hook for an 'apache MIME config' file on windows in a standard place (either pythonpath, or %system% or wherever) that it will check before going to common_types or to the registry.

Making this change doesn't require changing the API at all, just the implementation changes.

I don't think it is unreasonable to return a well-known extension for certain mime types, text/plain being the most obvious (and most in need of repair; .ksh??).

I've attached a patch based on the previous discussion.

Here is a related question on SO: http://stackoverflow.com/questions/352837/how-to-add-file-extensions-based-on-file-type-on-linux-unix

Anyone interested in picking this up, or at least commenting on the approach I suggested in the patch? Seems like an easy fix for a long-standing bug.

See also <https://bugs.python.org/issue6626#msg91205>, which mentions using a list of tuples instead of a dictionary, which sounds like it might help with this issue. Doing it that way you might be able avoid some duplication in the lists.

Confirming that I've also bumped into this for Python 3.5.

A docs update would seem to be the lowest-cost option to start with.

Right now `mimetypes.guess_extension()` isn't terribly useful, and it'd be better to at least know that upfront.

I think this has been fixed in Python 3.7+ via https://github.com/python/cpython/pull/14375 - at least for a couple of types.

Comparing Python 3.6 with the current state, the following changed (which can be used as an "override" dict before calling mimetypes.guess_extension):

    "application/manifest+json": ".webmanifest",  # not None
    "application/octet-stream": ".bin",  # not .a
    "application/postscript": ".ps",  # not .ai
    "application/vnd.ms-excel": ".xls",  # not .xlb
    "application/vnd.ms-powerpoint": ".ppt",  # not .pot
    "application/wasm": ".wasm",  # not None
    "application/x-hdf5": ".h5",  # not None
    "application/xml": ".xsl",  # not .rdf
    "audio/mpeg": ".mp3",  # not .mp2
    "image/jpeg": ".jpg",  # not .jpe
    "image/tiff": ".tiff",  # not .tif
    "text/html": ".html",  # not .htm
    "text/plain": ".txt",  # not .bat
    "video/mpeg": ".mpeg",  # not .m1v

PR14375 indeed adds a test for this as well (test_preferred_extension).