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
