2010/4/18 Łukasz Langa <luk...@langa.pl>:
> This is not a proper reply in terms of e-mail but I registered just a second
> ago just to write this post. So, here goes, replying to Frederik's message
> from Thu Apr 08 15:01:06 2010:
>
> Are you using some virtual env thing that might move modules around,
> btw?  I tried messing with the path to see if I could trick Python
> into importing the same thing twice on Windows, but failed under 2.6.
>
> This is actually quite simple. When you easy_install PIL, you get the
> "pollute the global namespace" variant (e.g. import Image). Django on the
> other hand expects the "be pollite within your own namespace" variant (e.g.
> from PIL import Image). So if there's any .pth file or symbolic link that is
> supposed to cover for that, your going to have an error:
> $ python
> Python 2.6.5 (r265:79063, Mar 26 2010, 16:07:38)
> [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import _imaging
>>>> import PIL._imaging
> AccessInit: hash collision: 3 for both 1 and 1

Interesting.  Can you repeat this with -v and report from where the
modules are loaded?

</F>

PS. For reference, here's the -v output for the above commands on a
2.6.5 stock install on Windows:

>>> import _imaging
# c:\python26\lib\encodings\cp850.pyc matches c:\python26\lib\encodings\cp850.py
import encodings.cp850 # precompiled from c:\python26\lib\encodings\cp850.pyc
import _imaging # dynamically loaded from
c:\python26\lib\site-packages\PIL\_imaging.pyd
>>> import PIL._imaging
import PIL # directory c:\python26\lib\site-packages\PIL
# c:\python26\lib\site-packages\PIL\__init__.pyc matches
c:\python26\lib\site-packages\PIL\__init__.py
import PIL # precompiled from c:\python26\lib\site-packages\PIL\__init__.pyc
import PIL._imaging # previously loaded
(c:\python26\lib\site-packages\PIL\_imaging.pyd)

Note the last line: python correctly figures out that both imports
refer to the same module.

> The problem is, the default easy_install distribution does not provide the
> PIL.* variant whereas no stable Django version is as of yet using the global
> namespace version (see http://code.djangoproject.com/ticket/6054). The fact
> is that they on multiple occasions refused to make that change, I wonder
> what made them change their decision. That way or the other, it's a
> setuptools PIL packaging issue. Maybe the easiest and most compatible
> solution would be to simply include a PIL.py file along the distro with
> contents of the like:
> import _imaging
> import Image
> import ImageFile
> ...
> I don't really have the experience to make any remarks here, let alone
> decisions. So, it's up to you :)
> --
> Best regards,
> Łukasz Langa
> tel. +48 791 080 144
> WWW http://lukasz.langa.pl/
>
> _______________________________________________
> Image-SIG maillist  -  image-...@python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>
_______________________________________________
Image-SIG maillist  -  Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig

Reply via email to