Repository navigation
Naming a file io.py causes cryptic error message #65401
Description
| BPO | 21202 |
|---|---|
| Nosy | @loewis, @Yhg1s, @brettcannon, @jcea, @ncoghlan, @vstinner, @ned-deily, @ezio-melotti, @bitdancer, @florentx |
| Files |
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-05-15.03:03:55.874>
created_at = <Date 2014-04-11.18:05:51.841>
labels = ['type-bug', 'docs']
title = 'Naming a file` io.py` causes cryptic error message'
updated_at = <Date 2019-05-15.03:03:55.873>
user = 'https://bugs.python.org/madisonmay'bugs.python.org fields:
activity = <Date 2019-05-15.03:03:55.873>
actor = 'vstinner'
assignee = 'docs@python'
closed = True
closed_date = <Date 2019-05-15.03:03:55.874>
closer = 'vstinner'
components = ['Documentation']
creation = <Date 2014-04-11.18:05:51.841>
creator = 'madison.may'
dependencies = []
files = ['34937']
hgrepos = ['238']
issue_num = 21202
keywords = ['patch']
message_count = 7.0
messages = ['215940', '215946', '215947', '215952', '216001', '216619', '342546']
nosy_count = 13.0
nosy_names = ['loewis', 'twouters', 'brett.cannon', 'jcea', 'ncoghlan', 'ctheune', 'vstinner', 'ned.deily', 'ezio.melotti', 'r.david.murray', 'flox', 'docs@python', 'madison.may']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue21202'
versions = ['Python 2.7', 'Python 3.5']
Activity
MadisonMay commentedon Apr 11, 2014
Naming a file
io.pyin the root directory of a project causes the following error on 2.7:Similar issues arise on 3.x., although the error message is a bit more useful:
At the very least we should ensure that the error message is a bit more straightforward and clear, as I imagine its not all that uncommon to cause this kind of conflict.
ned-deily commentedon Apr 11, 2014
Using a local module name that shadows one in the standard library is a very common "import trap". See, for example, https://ncoghlan_devs-python-notes.readthedocs.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap. I did a quick search through the documentation and didn't find an explicit reference to the general topic. If it isn't already, it probably should be mentioned in the tutorial and the FAQ. I don't think that 'io' should be special-cased.
brettcannon commentedon Apr 11, 2014
While mentioning something in the FAQ and/or tutorial is fine, I wouldn't want to change Python's message too much to deal with this unless it was extremely fast (e.g. we pre-generated a set and check that on ImportError and then modified the message only in those instances).
MadisonMay commentedon Apr 11, 2014
I definitely agree that io shouldn't be special cased, as it's more about the name shadowing issue that this specific example.
A simple docs addition would make me happy, to be honest.
loewis commentedon Apr 13, 2014
I think the AttributeError message should improve, and special-case certain common types, in particular modules. E.g. it could read
or even
AttributeError: <module 'io' from 'C:\\Program Files\\Python34\\lib\\io.py'> has no attribute 'BufferedIOBase'
IIUC, the first version would already have helped the OP, and the second version would have been dead-clear (except that it is a little verbose).
ctheune commentedon Apr 16, 2014
I managed to create a patch that relies (in hopefully reasonably safe manner) on embedding an object repr for identification in this and similar cases. This is basically what implements what Martin suggested.
Caveat emptor: my C knowledge is only good enough to be dangerous. Thomas Wouters and RDM helped me through it.
I haven't adapted the tests yet (lots of failures due to the output change) but I managed them to stop crashing.
The 'repr.py' in the root is my current testbed to see what's going on.
vstinner commentedon May 15, 2019
No activity for 5 years, I close the issue.