using custom objects as modules: AttributeErrors new in 3.5

[arigo]

BPO	24492
Nosy	@brettcannon, @arigo, @terryjreedy, @ncoghlan, @larryhastings, @ericsnowcurrently
Files	test_case.py issue24492.diff

^{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 = 'https://github.com/brettcannon'
closed_at = <Date 2015-08-14.18:11:34.680>
created_at = <Date 2015-06-23.17:40:13.694>
labels = ['interpreter-core', 'type-bug', 'release-blocker']
title = 'using custom objects as modules: AttributeErrors new in 3.5'
updated_at = <Date 2015-08-24.20:01:24.482>
user = 'https://github.com/arigo'

bugs.python.org fields:

activity = <Date 2015-08-24.20:01:24.482>
actor = 'python-dev'
assignee = 'brett.cannon'
closed = True
closed_date = <Date 2015-08-14.18:11:34.680>
closer = 'brett.cannon'
components = ['Interpreter Core']
creation = <Date 2015-06-23.17:40:13.694>
creator = 'arigo'
dependencies = []
files = ['39791', '40154']
hgrepos = []
issue_num = 24492
keywords = ['patch', '3.4regression']
message_count = 20.0
messages = ['245696', '245699', '245725', '245726', '245869', '246112', '248345', '248361', '248368', '248369', '248371', '248373', '248377', '248384', '248436', '248541', '248551', '248598', '248599', '249072']
nosy_count = 7.0
nosy_names = ['brett.cannon', 'arigo', 'terry.reedy', 'ncoghlan', 'larry', 'python-dev', 'eric.snow']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue24492'
versions = ['Python 3.5', 'Python 3.6']

[arigo]

A regression in 3.5: if we use custom objects as modules (like some projects do), then these custom objects may not have an attribute called "__name__". There is new code in 3.5 added for issue bpo-17636 which tries sometimes to read the "__name__" of a module when executing an import statement, and if this leads to an AttributeError, it will get propagated.

I imagine this could break real code using "try: except ImportError:". It _does_ break the tests of the "cffi" project, which try to check that some import of a nonexisting name correctly gives ImportError. Now it gives AttributeError("__name__") instead.

[larryhastings]

What's a sensible approach to ameliorate the problem? Gracefully muddle through without a __name__ on the imported object?

[arigo]

I'd guess so: if the PyObject_GetAttrId() fails, then ignore the rest of the code that was added in https://hg.python.org/cpython/rev/fded07a2d616 and jump straight to PyErr_Format(PyExc_ImportError, ...).

[arigo]

Also, if we want to be paranoid, the _PyObject_GetAttrId() can return anything, not necessarily a string object. This would make the following PyUnicode_FromFormat() fail. So maybe you also want to overwrite failures in PyUnicode_FromFormat() with the final ImportError. (It actually looks like a good--if convoluted--use case for exception chaining at the C level...)

[terryjreedy]

I view having a string __name__ attribute as part of quacking like a module (or class or function). Hence pseudonames like '<lambda>' (lambda expression) or <pyshell#n> (the module name for interactive input, where n is the line number). Is there a good reason for custom 'module' objects to not have a name? If so, the 'graceful muddle' precedent is to give them a pseudoname, such as <module>, perhaps with a prefix or suffix.

[larryhastings]

This is
a) marked as release blocker, and
b) is assigned to nobody.
This is not tenable.

While I want this fixed, I'm not going to hold up beta 3 for it.

[brettcannon]

Here is a patch that adds a test, fixes the issue, and for good measure stops assuming that __name__ will always be a string.

[brettcannon]

Larry, does this warrant going into 3.5.0?