Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin3!goblin2!goblin.stu.neva.ru!xlned.com!feeder7.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Gelonida N <gelonida@gmail.com>
Subject: mimetypes.guess_type broken in windows on py2.7 and python 3.X
Date: Wed, 26 Sep 2012 10:54:34 +0200
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1412.1348649689.27098.python-list@python.org>
Lines: 92
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:30169

Hi,

I'm still experiencing the pleasure of migrating legacy code from Python 
2.6. to 2.7 which I expected to be much less painful.
(In fact migration on Linux is rather smooth, but Windows is another story)


Let's take the simple command

import mimetypes
print mimetypes.guess_type('a.jpg')


The result an old pythons ( 2.7)
is  ('image/jpeg', None)

Ther result on non windows platform is
for python 2.7 / 3.X is the same

However. The result for 2.7 / 3.x on windows is now
('image/pjpeg', None)  # pjpeg instead of jpeg

On Windows many file suffixes  will report wrong mime types.

The problem is know for about two years.
http://bugs.python.org/issue10551


The main reason is, that under wWindows default values are
fetched from Python and then 'updated' mime-types are
fetched from the Windows registry.
The major problem is, that almost ALL windows PCs have BROKEN mime 
types. so the good predefined mime types are just replaced with broken 
MS mime types.


I wonder how many applications, that will try to migrate to 2.7 / 3.0 
will fail due to this incompatibility in the mimetypes library


There is a workaround (but first people have to detect the problem and 
to find it):
Add these two lines somewhere in your code BEFORE any other imported 
library might have called a mimetypes function

import mimetypes
mimetypes.init([])

I still wonder if it wouldn't be better to have the default behaviour of 
2.7 / 3.0 on windows such, that all the users who're not aware of this 
issue will not have their code broken.

My suggestion for windows would be to have following default behaviour:

- !st read the mimetypes from the registry if possible
- 2nd read the Python default mimetypes and override the
    'broken' MS definitions

Only if a user explicitely calls mimetypes.init() they would have 
differente behaviour.

The new behaviour breaks portability of Python code between Windows and 
Linux and I think the attempt should be to be as cross platform as 
possible. and not to be. At least one of the reasons why I use pythin 
is, that it allows to be rather cross-platform

An alternative suggestion could be to never read the registry or 
/etc/mimetypes by default.

What would definitely be rather important is add a big warning in the 
documentation and a recommendation of how to write cross platform 
compatible code.

Somebody developing on Linux might not even know, that the code will not 
work on windows jsst because of this tiny issue.


The unfortunate fact, that this issue was not fixed two years ago means, 
that perhaps meanwhile some code is out, that relies on the current 
behaviour. However I'm not sure, that anybody relies on the fact, that 
code will not work the same way on windows and on Linux.

Any thoughts?