Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

__spec__ is None inside 'coverage run -m' #838

Closed
RhysU opened this issue Aug 13, 2019 · 5 comments
Closed

__spec__ is None inside 'coverage run -m' #838

RhysU opened this issue Aug 13, 2019 · 5 comments
Labels
bug

Comments

@RhysU
Copy link

@RhysU RhysU commented Aug 13, 2019

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)
@RhysU RhysU added the bug label Aug 13, 2019
@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Aug 14, 2019

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

This comment has been minimized.

Copy link
Author

@RhysU RhysU commented Aug 14, 2019

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 added a commit that referenced this issue Nov 24, 2019
@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Nov 24, 2019

Fixed in 47d1659

@nedbat nedbat closed this Nov 24, 2019
@RhysU

This comment has been minimized.

Copy link
Author

@RhysU RhysU commented Nov 25, 2019

Thank you.

@nedbat

This comment has been minimized.

Copy link
Owner

@nedbat nedbat commented Dec 8, 2019

This was released as part of 5.0b2 today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.