homepage

0. windows specific
i. In the pyglet library, written for py2 and officially running in 3 after the stock installation that does the 2to3 conversion
ii. Omitting files which are unimportant for the issue, the package dir looks as
pyglet
 image
 codecs
 pil.py
(each package - subpackage has a proper __init__.py)
iii. In the pyglet repository checkout, near the begining of pil.py theres the block
try:
 import Image
except ImportError:
 from PIL import Image
That PIL refers to the pillow package (fork of PIL, and yes it its the recommended import line in pillow's doc)
iv. after installing with
 cd working_copy
 py -3.3 setup.py install
the same block looks as
try:
 import Image
except ImportError:
 from .PIL import Image
which is wrong, and precludes pyglet to import Pillow.
v. I tracked the problem to (CPython) LIB/lib2to3/fixes/fix_import.py
In method FixImport.probably_a_local_import the heuristic is
"if 'import name' is seen, look if theres a sibling file with that name, and if exists assume it needs to be a relative import"
The problem is that the implementation uses os.path.exists to check sibling existence, but that has false positive cases due to Windows case-insensivity for filenames.
Module names are case-sensitive.
So, the import machinery would never match PIL to pil, but the code in fix_import.py will merrily match.
vi. To verify the issue I patched fix_import.py, deleted the old pyglet install under 3, reinstalled: Now the block is unmolested.
Attached the diff with the fixed code (diff obtained with the GNU C utils)
vii. This was seen in python 3.3.1 , on Windows xp sp3.
I see in the cpython repo the same issue will happen in the default branch (the offending lines in fix_import.py are unchanged, so I assume 3.4 will show the same defect)
viii. as a reference, the original issue in pyglet can be found at
http://code.google.com/p/pyglet/issues/detail?id=707
ix. Anyone can suggest a workaround, a change in the problematic block in pyglet that would tell 2to3 to not change the block ?

Hello, thanks for the report. Is this the same issue as #19510?

No. #19510 is about 2 to 3 confused when the same import line has some modules that should be 'relativized' and others that not.
The present issue is about 2to3 incorrectly 'relativize' a module / package by forgetting that module names are case-sensitive but filenames are case-insensitive in windows.