4

I find this code in Django:

# Try to import PIL in either of the two ways it can end up installed.
try:
    from PIL import ImageFile as PILImageFile
except ImportError:
    import ImageFile as PILImageFile

and up until recently, I just blew it off as unimportant. However I built PIL under my virtualenv in windows and all of a sudden

from PIL import Image

doesn't work anymore, I have to use

import Image

So, now I want to understand why and what is going on.

Initially I was using PIL installed with the windows installer. But I needed read support for Group4 Faxes so I did the mods and then got PIL to build and install under virtualenv on windows (something that is trivial on linux and a PITA on windows). But, now I have to use the second form of import, even though pip freeze shows that PIL==1.1.7 in installed.

How is it that first import form doesn't work even though PIL appears to be installed, and the second form works (and the PIL code is functioning), indicating it is installed, but doesn't show up under PIL.

Community
  • 1
  • 1
boatcoder
  • 17,525
  • 18
  • 114
  • 178

1 Answers1

4

Edit: From the comment to my answer by @cgohlke, this will change in PIL1.2:

the support for importing from the standard namespace [has been dropped]; PIL now lives in the PIL namespace only

I think the Django comment is pretty clear:

# Try to import PIL in either of the two ways it can end up installed.

PIL can either be installed as a single package, and you access the modules within it:

from PIL import ImageFile as PILImageFile

or the modules can each be installed separately:

import ImageFile as PILImageFile

So PIL is installed, it is just split up into it's component modules.

It's also the issue in The problem with installing PIL using virtualenv or buildout, and @Ignacio mentions in a comment that the PIL tutorial actually expects it to be installed this way, the very first chunk of code starts:

>>> import Image

not from PIL import Image.

I agree this is confusing behavior, but I guess it's a relatively large package so they might think it's easier to not have to deal with an extra level of depth.

This seems to be the problem in Python - package installed with easy_install is not being detected (PIL 1.1.7) although only the last answerer there figured it out, the rest of the people don't know what is going on.

Community
  • 1
  • 1
agf
  • 171,228
  • 44
  • 289
  • 238
  • 1
    In my case, I'm installing it as `python setup.py install` and I have to do `import Image`. When I use the windows Installer, I use `from PIL import Image`. [I figured out a way to manually fix it](http://codemonkey.intomec.com/blog/group-4-faxes-with-pil/) and added it to my blog. – boatcoder Aug 20 '11 at 17:35
  • Hence the question, what is actually going on with PIL. Obviously something is messed up or packages like Django wouldn't have workarounds to deal with the "2 ways" it can be installed. – boatcoder Aug 20 '11 at 17:44
  • But the point is that you shouldn't "Fix" it, it's considered correct behavior. It's also funny that you linked to your own blog and yet it's a (perhaps temporarily) dead link. – agf Aug 20 '11 at 17:45
  • python setup.py install leaves it unencapsulated, using the windows installer leaves it encapsulated. Both of those are from the same author, consistent it isn't. Because of that lack of consistency we see hacks in the Django code. SOMETHING is wrong. – boatcoder Aug 20 '11 at 17:49
  • 2
    Note that `import Image` will not work any longer in PIL 1.2+ – cgohlke Aug 20 '11 at 21:37
  • Edited into my post, nice job finding that. – agf Aug 20 '11 at 21:39
  • I wish this failed at import time. Instead, when I upgraded PIL, `Image.open` just started failing for me with `IOError: cannot identify image file 'test.jpg'`. – kuzzooroo Sep 05 '15 at 15:48