In PyPy 2.3, modules like _structseq had a
__file__ attribute with build-system file paths in them, like '/Users/kostia/programming/pypy/lib_pypy/_structseq.pyc'. This was weird:
$ pypy2.3 Python 2.7.6 (32f35069a16d, Jun 06 2014, 20:12:47) [PyPy 2.3.1 with GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> import _structseq >>>> _structseq.__file__ '/Users/kostia/programming/pypy/lib_pypy/_structseq.pyc'
In PyPy 2.4, that attribute is gone, but you can still find paths like that in func_code.co_filename:
$ pypy2.4 Python 2.7.8 (f5dcc2477b97, Sep 19 2014, 18:09:54) [PyPy 2.4.0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>> import _structseq >>>> _structseq.__file__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute '__file__' >>>> _structseq.structseq_new.func_code.co_filename '/Users/kostia/programming/pypy/lib_pypy/_structseq.py'
This mattered to coverage.py, because it was excluding the PyPy stdlib modules based on where _structseq was from. Without a
__file__ attribute, coverage wasn't excluding the stdlib modules, and _structseq would be measured, but would then fail during reporting when coverage.py couldn't read the co_filename path to produce the report.
Coverage.py is now fixed with this: https://bitbucket.org/ned/coveragepy/commits/789cc15f04ccb46b53e96e5ffd3debbfbc1defaa , but Alex asked that I write a bug, and I do what Alex asks me to! :)