Naming a file `io.py` in the root directory of a project causes the following error on 2.7: 

    AttributeError: 'module' object has no attribute 'BufferedIOBase'

Similar issues arise on 3.x., although the error message is a bit more useful:

    Fatal Python error: Py_Initialize: can't initialize sys standard streams
    AttributeError: 'module' object has no attribute 'OpenWrapper'

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.

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.

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).

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.

I think the AttributeError message should improve, and special-case certain common types, in particular modules. E.g. it could read

    AttributeError: module 'io' has no attribute 'BufferedIOBase'

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).

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.

No activity for 5 years, I close the issue.