ImportError messages should quote the name it cannot import since the actual problem may be whitespace in the name that is currently invisible in the message.  In other words, display

ImportError: no module named 'bad name\r'

instead of

ImportError: no module named bad name

This defect lead to the current python-list thread
  pickle unable to load collection

Peter Otten figured out that it was unable to load 'collections\r' rather than 'collections', which he demonstrated with

>>> >>> try: pickle.loads(garbled_data)
... except ImportError as e:
...     e
...
ImportError('No module named collections\r',)

The OP used 2.6, I tested 3.1, hence presume, after searching tracker issues, that this applies to 2.7 and 3.2 as well.

I marked this as a bug since the current message is wrong and misleading. I suspect the same may be true of a few other error messages, but I cannot think of any at the moment.

I guess it's a question of readability. Does::

  ImportError: No module named mod

read better than::

  ImportError: No module named 'mod'

In my eyes it doesn't by much, so switching to using repr() seems reasonable.

This can't be changed in released versions of Python as that could break someone's doctests. So making this only for 2.7 and 3.2.

A refinement would be to only quote when there is whitespace in the name, but I do not know how well that works with unicode versus ascii.

It wouldn't matter (at least in Python 3) as str is unicode-aware. It's more about whether it's worth special-casing the output. I say no and just go with using the repr.

A question about process: Should every import bug be reported against core and library, so that importlib gets patched too?

I think everyone knows that importlib is there and might need to be patched. Plus I run importlib against the entire test suite already on occasion so changes which has a proper test will eventually get caught.

So just file it against core.

Thanks for the reply.

Funny thing, grep revealed a small inconsistency in this error message:

Python/pythonrun.c:415:     * XXX     Exception exceptions.ImportError: 'No module named sha'
Python/import.c:1821:                     "No module named %.200s", name);
Python/import.c:2722:                     "No module named %.200s", name);
Lib/test/test_multiprocessing.py:27:# message: "No module named _multiprocessing". _multiprocessing is not compiled
Lib/test/test_concurrent_futures.py:8:# message: "No module named _multiprocessing". _multiprocessing is not compiled
Lib/test/test_pydoc.py:194:badimport_pattern = "problem in %s - ImportError: No module named %s"
Lib/runpy.py:104:        raise ImportError("No module named %s" % mod_name)
Lib/xml/etree/ElementTree.py:1492:                    "No module named expat; use SimpleXMLTreeBuilder instead"
Lib/modulefinder.py:189:        self.msgout(4, "raise ImportError: No module named", qname)
Lib/modulefinder.py:190:        raise ImportError("No module named " + qname)
Lib/modulefinder.py:202:                self.msgout(4, "raise ImportError: No module named", mname)
Lib/modulefinder.py:203:                raise ImportError("No module named " + mname)
Lib/modulefinder.py:219:                    raise ImportError("No module named " + subname)
Lib/importlib/_bootstrap.py:811:                raise ImportError("no module named {}; "
Lib/importlib/_bootstrap.py:820:            raise ImportError("No module named {0}".format(name))
Lib/unittest/test/test_loader.py:242:            self.assertEqual(str(e), "No module named sdasfasfasdf")
Lib/unittest/test/test_loader.py:622:            self.assertEqual(str(e), "No module named sdasfasfasdf")

Fixing the Python modules is easy, but I don’t know how to change PyErr_Format (or how to write C, for that matter :)  Do you make offers like Alexandre, who has proposed to write the C part if someone provides a diff for the Python version?

I should have included only the one line that’s different:
Lib/importlib/_bootstrap.py:811:                raise ImportError("no
(lower-case n)

PyErr_Format doesn't need to change, just it's argument. A call to PyObject_Repr() (w/ proper error checking) should be all that is needed.

And no, I don't make any "you do the Python, I'll do the C" deals because the Python part is the fun part. =)

> A call to PyObject_Repr() (w/ proper error checking) should be all
> that is needed.
Sadly out of reach for me.

> And no, I don't make any "you do the Python, I'll do the C" deals
> because the Python part is the fun part. =)
I understand :)

FTR, case inconsistency fixed by Brett in r86507.

Just for fun, I tried using my tiny understanding of C to write a patch. I am attaching my current result, which passes the test suite except for test_unittest:

FAIL: test_loadTestsFromName__unknown_module_name (unittest.test.test_loader.Test_TestLoader)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wok/code/hg/cpython/3.2/fix-import-repr/Lib/unittest/test/test_loader.py", line 240, in test_loadTestsFromName__unknown_module_name
    loader.loadTestsFromName('sdasfasfasdf')
ImportError: No module named 0I�


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/wok/code/hg/cpython/3.2/fix-import-repr/Lib/unittest/test/test_loader.py", line 242, in test_loadTestsFromName__unknown_module_name
    self.assertEqual(str(e), "No module named 'sdasfasfasdf'")
AssertionError: 'No module named 0I�\x01' != "No module named 'sdasfasfasdf'"
- No module named 0I�

+ No module named 'sdasfasfasdf'


======================================================================
FAIL: test_loadTestsFromNames__unknown_module_name (unittest.test.test_loader.Test_TestLoader)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/unittest/test/test_loader.py", line 620, in test_loadTestsFromNames__unknown_module_name
    loader.loadTestsFromNames(['sdasfasfasdf'])
ImportError: No module named HB�


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib/unittest/test/test_loader.py", line 622, in test_loadTestsFromNames__unknown_module_name
    self.assertEqual(str(e), "No module named 'sdasfasfasdf'")
AssertionError: 'No module named HB�\x01' != "No module named 'sdasfasfasdf'"
- No module named HB�

+ No module named 'sdasfasfasdf'

test_imp{,ort,ortlib} pass, though.  Maybe someone will take my patch and fix the PyObject_Repr call and error checking.  It was a fun bit of experimenting with help from kind people on IRC :)

I fixed my patch, thanks to a recent commit that showed me an example of PyErr_Format :)  All tests now pass.

The patch looks same to me as far as I can judge. I would have used .format instead of %, but you wrote it ;-).

Seeing how many of our tests had to be patched convinced me that we should treat this like a feature request and only apply to 3.2.

> The patch looks same to me as far as I can judge.
Thanks.  Can you apply the patch on your Windows machine and run the test suite?

> I would have used .format instead of %, but you wrote it ;-).
I would have too, were I writing Python :)  Here I tried to do the simplest thing that could work.

> Seeing how many of our tests had to be patched convinced me that we
> should treat this like a feature request and only apply to 3.2.
Yes, as an incompatible behaviour change I cannot go into released versions, as Brett stated in msg105994.

Does someone have time to review?  I think this would be a good change for 3.2.

Georg, please lower the priority if you think this can wait for 3.3.

The change would be fine with me.  What happens with the PyUnicode_FromString() usage in the patch if the string cannot be decoded?  That should not lead to a UnicodeError being raised.

Also, the __main__ changes look gratuitous to me.

Deferring, this is not a bug.

I set LANG and LC_ALL to C and tried to import a module with a non-ASCII name:
    $ ./python -m échec™♥
    python: No module named '\udcc3\udca9chec\udce2\udc84\udca2\udce2\udc99\udca5'
Is that a good enough test?

I guess the “__main__ changes” you’re talking about are the addition of single quotes around __main__ in some error messages; that was only for the sake of consistency.

I suppose it's not a good test, since your non-ascii name presumably was encoded in UTF-8, which is the encoding that PyUnicode_FromString uses.

Won't make it into 3.2.

My patch for #3080 uses repr() to format module name in all error messages.

Victor: Should I close this bug as superseded by yours?

Victor changed the code to use repr in some modules but not all in c4361bab6914.

New changeset 9f9b7b656761 by Brett Cannon in branch 'default':
Have importlib use the repr of a module name in error messages.
http://hg.python.org/cpython/rev/9f9b7b656761

I patched import.c to use repr() instead of str() (%R instead of %U) to format module names because they might contain surrogate characters. Surrogate characters are not encodable to any encoding, except UTF-16 and UTF-32. And so print an exception to stdout may produce an UnicodeEncodeError. At the same time... exceptions are printed to stderr which uses the backslashreplace error handler, and so the message *can* be printed:

$ python3.1
>>> raise Exception('x\uDC80y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Exception: x\udc80y

So now I realized that my change was maybe useless.

Victor changed ImportError some time ago for #3080, so my patch now only touches a few stdlib modules.

With issue1559549 adding a 'name' argument, I'm going to push to have it gain a reasonable default __str__ if 'name' is set but nothing else. That patch also contains some helper functions which should simplify Eric's patch.

> With issue1559549 adding a 'name' argument, I'm going to push to have it gain a reasonable default
> __str__ if 'name' is set but nothing else. That patch also contains some helper functions which
> should simplify Eric's patch.

Maybe you’re talking about my first patch?  The latest one does not touch C code and I don’t see why it depends on the other bug.

It technically doesn't depend, but it potentially would make this moot. But stuff is going on at the language summit which is going to shift stuff around.

Over time I have fixed this issue in various patches.

Great!