Try importing _imaging from PIL namespace first.

[Richard Xia]

Patch available at ​https://github.com/django/django/pull/1819. Fixes problem described in #20964.

On an OS X system with a Homebrew version of Python/PIL installed, the django/utils/image module encounters a hash collision error when trying to import _imaging, as described in #20964. Although that ticket was closed for not being a problem with Django, the ticket it references in the Homebrew project (​https://github.com/mxcl/homebrew/issues/22135) only resulted in removing PIL from the core Homebrew libraries without actually fixing the original import issue. Everyone in the Homebrew ticket discussion agrees that pillow should be used in place of PIL, but because Django isn't officially removing support for PIL until 1.8, I believe that this problem deserves to be fixed in time for 1.6.

In my patch, I attempt to import _imaging from the PIL namespace first, which prevents the hash collision error because the _imaging module will imported using the same filesystem path as when imported through the earlier from PIL import Image statement. If _imaging isn't available under PIL, then it attempts to import _imaging directly just as did before. This allows PIL to be properly imported in my setup (OS X 10.8, Homebrew Python/PIL) and should still be compatible with environments in which the PIL namespace isn't available.

[Anssi Kääriäinen]

I'll close this as wontfix. If you must use Homebrew, then use Pillow.

ptone: I see you are in cc - if you are planning on doing something to this, just revert my wontfix.

[leo+django@…]

We actually have the exact same issue on a CentOS 6.4 with python-imaging (for PIL) and mod_wsgi both from CentOS. We are trying to use Django 1.6, but when using a django.forms.ImageField we are getting the error message:

ImproperlyConfigured: The '_imaging' module for the PIL could not be imported: No module named _imaging

The fix by richardxia (trying "from PIL import _imaging as PIL_imaging" first) works for us. I don't see why this shouldn't go into the official release as it seems harmless and works exactly the same as the PILImage import just a few lines above. Considering our pretty clean CentOS 6 simple setup I don't think we will be the only ones that run into this as more people migrate to Django 1.6.

Can the "wontfix" decision be re-evaluated?

[Anssi Kääriäinen]

OK, so it seems this isn't Homebrew issue. I'll mark this as release blocker for 1.6. I am not sure what we should do about this. If the patch really is safe (I can't tell) then we should likely backpatch.

By marking this as release blocker I want to assure that we at least consider doing something to this before 1.6.1.

[Anssi Kääriäinen]

I think I will just commit the fix. The fix seems safe, and it seems there are some setups where the fix is needed.

Any objections?

[Anssi Kääriäinen <akaariai@…>]

In 5725236c3ee4323203aa681cb54d1ff1d7f376df:

Fixed #21355 -- try importing _imaging from PIL namespace first.

[Anssi Kääriäinen <akaariai@…>]

In 6cd5c67b694b3469817e38d02f79ddef7c2a7132:

[1.6.x] Fixed #21355 -- try importing _imaging from PIL namespace first.

Backport of 5725236c3e from master