[pypy-issue] Issue #1885: RPython modules no longer have __file__, but their functions have func_code.co_filename (pypy/pypy)

[Ned Batchelder]

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! :)