__spec__ is None inside 'coverage run -m'

[RhysU]

Describe the bug
Unlike python -m, inside coverage run -m it turns out __spec__ is unexpectedly None.

To Reproduce

$ python --version
Python 3.5.6 :: Anaconda, Inc.

$ coverage --version
Coverage.py, version 4.5.1 with C extension
Documentation at https://coverage.readthedocs.io

$ cat foo.py 
print(__name__)
print(__spec__.name)

$ python -m foo  # Behaves as expected
__main__
foo

$ coverage run -m foo  # Observe __spec__ is None
__main__
Traceback (most recent call last):
  File "/nas/dft/ire/rhys/Build/liquidmetal-debt/foo.py", line 2, in <module>
    print(__spec__.name)
AttributeError: 'NoneType' object has no attribute 'name'
Coverage.py warning: No data was collected. (no-data-collected)

[nedbat]

Thanks. Do you know anything about how to set it properly? Maybe now is the time to switch to using runpy in the stdlib?

[RhysU]

I don't know any particulars on runpy. Never knew it existed. :)

FWIW, I do see __spec__ reflect 'foo' like I'd expect:

$ cat foo.py 
print(__name__)
print(__spec__.name)

$ python -m runpy foo
__main__
foo

Per the manual:

The special global variables name, spec, file, cached, loader and package are set in the globals dictionary before the module code is executed (Note that this is a minimal set of variables - other variables may be set implicitly as an interpreter implementation detail).

Discussion there around PEP 451 suggests the spec handling may only be correct post Python 3.4. I've not tested anything in this manner.

[nedbat]

Fixed in 47d1659

[RhysU]

Thank you.

[nedbat]

This was released as part of 5.0b2 today.