using custom objects as modules: AttributeErrors new in 3.5 #68680

arigo · 2015-06-23T17:40:14Z

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 · 2015-06-23T17:40:14Z

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 · 2015-06-23T19:52:51Z

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

arigo · 2015-06-24T08:29:24Z

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 · 2015-06-24T08:35:18Z

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 · 2015-06-26T21:05:19Z

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 · 2015-07-03T00:52:54Z

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 · 2015-08-09T23:40:00Z

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 · 2015-08-10T16:50:30Z

Larry, does this warrant going into 3.5.0?

larryhastings · 2015-08-10T20:44:10Z

I would like the fix in 3.5. However, I'm not qualified to review the code. Can you get a qualified reviewer in to look over the code?

Once someone suitable has reviewed it, I'll accept a pull request (pasted in here naturally).

ericsnowcurrently · 2015-08-10T21:08:36Z

patch LGTM. Presumably the divergence between importlib (in _handle_fromlist) and import.c was strictly accidental (i.e. lack of test coverage).

arigo · 2015-08-10T21:24:55Z

Patch LGTM too. Optionally a test is needed for each of the other cases in it too, but please don't cause that comment to stop it from getting in.

brettcannon · 2015-08-10T21:36:34Z

Thanks for the reviews, Eric and Armin. I will get the patch in 3.5.0, 3.5.1, and 3.6 sometime this week and then open another issue for adding more tests for the other branches in the code.

larryhastings · 2015-08-10T22:51:34Z

Yes, Eric and Armin are both qualified reviewers in my book. You have my blessing to send a pull request.

Thanks, everybody!

larryhastings · 2015-08-11T00:29:19Z

My Bitbucket repo is now public.

https://bitbucket.org/larry/cpython350

brettcannon · 2015-08-12T01:10:28Z

Created https://bitbucket.org/larry/cpython350/pull-requests/2/issue-24492-make-sure-that-from-import/diff without the PyUnicode_FromFormat() change as I realized that was conflating two changes in one patch and it wasn't even being tested (verified all tests still pass and a quick check in the interpreter shows ImportError is still raised).

Larry, let me know when you have accepted the PR and I will commit to 3.5 and default on hg.python.org.

I also created http://bugs.python.org/issue24846 to track adding more tests for the code.

brettcannon · 2015-08-13T21:45:27Z

I noticed you accepted the PR on Bitbucket, Larry. Should I consider your part done and I can now pull the commit into the 3.5 and default branches on hg.python.org?

larryhastings · 2015-08-14T01:44:11Z

Yep. This time I have foisted nearly all the work, including the forward-merging, onto y'all.

*sits back, sips iced coffee*

python-dev · 2015-08-14T18:10:30Z

New changeset cf3a62a8d786 by Brett Cannon in branch '3.5':
Issue bpo-24492: make sure that ``from ... import ...` raises an
https://hg.python.org/cpython/rev/cf3a62a8d786

New changeset bbe6b215df5d by Brett Cannon in branch '3.5':
Merge from 3.5.0 for issue bpo-24492
https://hg.python.org/cpython/rev/bbe6b215df5d

New changeset b0a6bba16b9c by Brett Cannon in branch 'default':
Merge from 3.5 for issue bpo-24492
https://hg.python.org/cpython/rev/b0a6bba16b9c

brettcannon · 2015-08-14T18:11:35Z

I have merged my 3.5.0 patch into 3.5 and default, so that should fix the issue Armin and CFFI was having.

python-dev · 2015-08-24T20:01:24Z

New changeset 5a9ac801f9b4 by larry in branch '3.5':
Merged in brettcannon/cpython350/3.5 (pull request #2)
https://hg.python.org/cpython/rev/5a9ac801f9b4

arigo mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Jun 23, 2015

bitdancer added the release-blocker label Jun 23, 2015

larryhastings added deferred-blocker and removed release-blocker labels Jul 3, 2015

brettcannon self-assigned this Aug 9, 2015

brettcannon assigned larryhastings and unassigned brettcannon Aug 10, 2015

larryhastings assigned brettcannon and unassigned larryhastings Aug 10, 2015

brettcannon added release-blocker and removed deferred-blocker labels Aug 10, 2015

brettcannon assigned larryhastings and unassigned brettcannon Aug 12, 2015

brettcannon closed this as completed Aug 14, 2015

brettcannon assigned brettcannon and unassigned larryhastings Aug 14, 2015

ezio-melotti transferred this issue from another repository Apr 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

using custom objects as modules: AttributeErrors new in 3.5 #68680

using custom objects as modules: AttributeErrors new in 3.5 #68680

arigo mannequin commented Jun 23, 2015

arigo mannequin commented Jun 23, 2015

larryhastings commented Jun 23, 2015

arigo mannequin commented Jun 24, 2015

arigo mannequin commented Jun 24, 2015

terryjreedy commented Jun 26, 2015

larryhastings commented Jul 3, 2015

brettcannon commented Aug 9, 2015

brettcannon commented Aug 10, 2015

larryhastings commented Aug 10, 2015

ericsnowcurrently commented Aug 10, 2015

arigo mannequin commented Aug 10, 2015

brettcannon commented Aug 10, 2015

larryhastings commented Aug 10, 2015

larryhastings commented Aug 11, 2015

brettcannon commented Aug 12, 2015

brettcannon commented Aug 13, 2015

larryhastings commented Aug 14, 2015

python-dev mannequin commented Aug 14, 2015

brettcannon commented Aug 14, 2015

python-dev mannequin commented Aug 24, 2015

using custom objects as modules: AttributeErrors new in 3.5 #68680

using custom objects as modules: AttributeErrors new in 3.5 #68680

Comments

arigo mannequin commented Jun 23, 2015

arigo mannequin commented Jun 23, 2015

larryhastings commented Jun 23, 2015

arigo mannequin commented Jun 24, 2015

arigo mannequin commented Jun 24, 2015

terryjreedy commented Jun 26, 2015

larryhastings commented Jul 3, 2015

brettcannon commented Aug 9, 2015

brettcannon commented Aug 10, 2015

larryhastings commented Aug 10, 2015

ericsnowcurrently commented Aug 10, 2015

arigo mannequin commented Aug 10, 2015

brettcannon commented Aug 10, 2015

larryhastings commented Aug 10, 2015

larryhastings commented Aug 11, 2015

brettcannon commented Aug 12, 2015

brettcannon commented Aug 13, 2015

larryhastings commented Aug 14, 2015

python-dev mannequin commented Aug 14, 2015

brettcannon commented Aug 14, 2015

python-dev mannequin commented Aug 24, 2015