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

Unexpected exception with importlib #79972

Closed
ronaldoussoren opened this issue Jan 20, 2019 · 6 comments
Closed

Unexpected exception with importlib #79972

ronaldoussoren opened this issue Jan 20, 2019 · 6 comments
Labels
3.7 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ronaldoussoren
Copy link
Contributor

BPO 35791
Nosy @brettcannon, @ronaldoussoren, @ncoghlan, @ericsnowcurrently

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-01-22.11:47:52.046>
created_at = <Date 2019-01-20.17:38:23.909>
labels = ['3.7', 'invalid', 'type-bug', 'library']
title = 'Unexpected exception with importlib'
updated_at = <Date 2019-01-28.07:00:42.610>
user = 'https://github.com/ronaldoussoren'

bugs.python.org fields:

activity = <Date 2019-01-28.07:00:42.610>
actor = 'ncoghlan'
assignee = 'none'
closed = True
closed_date = <Date 2019-01-22.11:47:52.046>
closer = 'ncoghlan'
components = ['Library (Lib)']
creation = <Date 2019-01-20.17:38:23.909>
creator = 'ronaldoussoren'
dependencies = []
files = []
hgrepos = []
issue_num = 35791
keywords = []
message_count = 6.0
messages = ['334094', '334095', '334207', '334212', '334223', '334449']
nosy_count = 4.0
nosy_names = ['brett.cannon', 'ronaldoussoren', 'ncoghlan', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue35791'
versions = ['Python 3.7']

@ronaldoussoren
Copy link
Contributor Author

Using Python 3.7.2 on macOS 10.14 I get an unexpected exception when calling "importlib.util.find_spec('py')" after importing "py". find_spec works as expected before I import 'py'.

See the repl session below:

Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib.util
>>> importlib.util.find_spec("py")
ModuleSpec(name='py', loader=<_frozen_importlib_external.SourceFileLoader object at 0x10a953fd0>, origin='/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/py/__init__.py', submodule_search_locations=['/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/py'])
>>> import py
>>> importlib.util.find_spec("py")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/importlib/util.py", line 111, in find_spec
    raise ValueError('{}.__spec__ is not set'.format(name)) from None
ValueError: py.__spec__ is not set

This is with py version 1.7.0 installed (pip install py)

@ronaldoussoren ronaldoussoren added 3.7 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Jan 20, 2019
@ronaldoussoren
Copy link
Contributor Author

This might be a bug in "py", which uses a vendored version of apipkg that replaces sys.modules["py"] with a lazy loading object. That copy of apipkg does not copy __spec__ into the lazy loading object.

If this is indeed consider to be a bug in py I'll file an issue with them.

@ncoghlan
Copy link
Contributor

Yep, that's a bug in py's module interface emulation - see the last paragraph in https://docs.python.org/3/reference/import.html#module-spec

@ronaldoussoren
Copy link
Contributor Author

I expected as much.

I've filed an issue with apipkg for this: pytest-dev/apipkg#13.

My next challenge is to find a way to work around this issue in my code.

BTW. Typing.io is a namespace added to sys.modules by the typing module that also does not have __spec__, and causes similar problems. I have an simple workaround for that on my side.

@ericsnowcurrently
Copy link
Member

FYI, I opened bpo-35806 for typing.io.

@ncoghlan
Copy link
Contributor

bpo-35839 is follow-up enhancement request, proposing that we tweak the sys.modules handling in find_spec to ignore cache entries that don't have a __spec__ attribute set.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.7 (EOL) end of life stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants