mimetypes.guess_type broken in windows on py2.7 and python 3.X

Discussion in 'Python' started by Gelonida N, Sep 26, 2012.

  1. Gelonida N

    Gelonida N Guest


    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.

    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

    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?
    Gelonida N, Sep 26, 2012
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Holger Joukl

    py2.1->py2.3.3 __getattr__ confusion

    Holger Joukl, Jul 2, 2004, in forum: Python
    Peter Otten
    Jul 2, 2004
  2. Holger Joukl
    Michael Hudson
    Jul 9, 2004
  3. GHUM
  4. Josef Dalcolmo

    getmtime differs between Py2.5 and Py2.4

    Josef Dalcolmo, May 7, 2007, in forum: Python
    Joe Salmeri
    Jun 1, 2007
  5. Sion Arrowsmith

    mimetypes oddity

    Sion Arrowsmith, Jan 15, 2009, in forum: Python
    Terry Reedy
    Jan 16, 2009

Share This Page