R. David Murray added the comment: It is not true that __file__ will always end with '.py'. If *only* the .pyc or .pyo file exists (not the PEP 3147 version, but just modname.pyc on the pythonpath), then __file__ will end with .pyc. It is also the case that __file__ may end with something *else*, such as .so on unix and .pyd on Windows, as it does in this particular case.
So, dropping the extension check is the wrong logic fix. The correct fix is to make sure it isn't '.py', because the original check was making sure there wasn't source code to load. When might unicodedata be a python file and not a sourceless (from inspect's point of view) binary? pypy :) I have no idea if this is actually an issue on pypy, but I'd hate to introduce a new failure for them in the process of doing a cleanup. The reason for the __file__ check is that we are looking for an *external* compiled module for the test. Originally I used time, but that failed on windows because time is part of the main binary on windows and has no __file__ attribute. The idea behind doing the __file__ check is that someone re-packaging python might move unicodedata into the main binary on windows, since if I understand correctly which modules are included there is somewhat arbitrary. ---------- nosy: +r.david.murray resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12780> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
