New issue 1885: RPython modules no longer have __file__, but their functions have func_code.co_filename https://bitbucket.org/pypy/pypy/issue/1885/rpython-modules-no-longer-have-__file__
Ned Batchelder: 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.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! :) _______________________________________________ pypy-issue mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-issue
