Issue #132 resolved

__file__ is different when run under coverage

Luke Plant
created an issue

Steps to reproduce:

Create:

{{{mypackage/}}} (dir)

{{{mypackage/init.py}}} (empty)

{{{mypackage/mymodule.py}}} - containing: {{{ print file }}} Then:

main.py - executable, containing:

{{{

!/usr/bin/env python

import mypackage.mymodule }}}

If run manually:

{{{ $ ./main.py /home/luke/mypackage/mymodule.py }}}

If run through coverage: {{{ $ coverage run ./main.py ./mypackage/mymodule.pyc }}}

There are two differences - the initial path shown, and the suffix. It's the first one that's bothering me - it currently causes a bunch of tests in the Django test suite to fail when run under coverage, when they pass normally. I'm sure this isn't the only case where this difference might affect program behaviour.

I understand that this might be tricky to avoid for technical reasons, but it would be good to know that before I attempt to change the tests to be more robust.

Comments (3)

  1. Ned Batchelder repo owner

    When I try this, I see two differences from your report:

    1) The first time I run through your scenario, main.py reports an extension of .py for the file, and coverage reports an extension of .pyc, but this is not about "./main.py" vs "coverage run ./main.py", it's about whether mymodule.py has already been compiled or not. If you clean the directory, and run the two techniques in the other order, then coverage reports .py, and ./main.py reports .pyc. So this is not an issue with coverage, it's just the way Python reports modules differently based on whether it compiled the file when it was imported.

    2) With the tip of the trunk, I see the same absolute file path for both running techniques. I've only recently fixed a bug whereby the current directory auto-inserted into sys.path was relative under coverage where it is absolute under Python. I think this has fixed your problem. It's in changeset 811ed58de8a3 .

  2. Luke Plant reporter

    Regarding (1) - yeah, I could have worked that out! Shouldn't file bugs so late at night...

    Regarding (2) - yes, this has indeed fixed my bug. Thanks!

  3. Log in to comment