This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients barry, benjamin.peterson, eric.araujo, python-dev, r.david.murray, vinay.sajip
Date 2014-10-03.15:19:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2014-10-03 15:20:00r.david.murraysetrecipients: + r.david.murray, barry, vinay.sajip, benjamin.peterson, eric.araujo, python-dev
2014-10-03 15:20:00r.david.murraysetmessageid: <>
2014-10-03 15:20:00r.david.murraylinkissue12780 messages
2014-10-03 15:19:59r.david.murraycreate