When importing the curses module, be it on Windows or Darwin or UNIX-based OS or any other platform, if the _curses module is not found then just a ModuleNotFoundError is raised. But this error is not very informational in case of _curses module. Since the curses module is packaged with the Python interpreter itself at first it may seem, to beginners especially, that the Python interpreter was not installed correctly and then they would go searching for an answer for about 4-5 days. 

We know that curses library is not installed on windows by default and may or may not be present on other operating systems. Most UNIX system have ncurses or other curses library installed by default. 

Python errors have a reputation of being very informational. I would like to submit a PR to modify the curses module a little bit by declaring a BaseException class and raising that Exception with the message "_curses module not found. Make sure a curses library is installed" or some kind of message like that.

But before I do that I would like to take advice from experienced developers about somethings. Is this change in the exception, raised when _curses module is not found, acceptable by the Python Community? If it is then should a draft PEP be submitted or should a PR be directly submitted to python/cpython?

ModuleNotFoundError is the correct exception. Its purpose is to be raised for missed modules.

I do not know about macOS, but the curses module is not supported on Windows, so it is expected to get ModuleNotFoundError.

Some distributions can provide some stdlib modules (like tkinter, or distutils, or tests) as separate packages.

The curses module is not supported on all platforms is very clear. But beginners may seem to think that their python was not installed properly and then they would go around looking for answer. To make it clear I was thinking of how about changing just the message and if required then the type (maybe CursesNotFoundError exception class derived from ModuleNotFoundError class) so that the error message became a little bit informational. The message could be like "_curses library not installed. Install a supported curses library to use the curses module" or something like that? 

The exception right now looks like this :-

ModuleNotFoundError: No module named '_curses'

What about something like this :-

CursesNotFoundError: "_curses library not installed. Install a supported curses library to use the curses module."

N.B.: The curses library still can be used on Windows by using the UniCurses library or Christoph Gohlke's unofficial curses or some other third party library.

What about only changing the error message to make it a little bit informational? Something like :-

ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module.

> ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module.

Is installing _curses possible, on any supported platform? Or would a better message say that curses is not supported on this platform?

> Is installing _curses possible, on any supported platform? Or would a better message say that curses is not supported on this platform?

No _curses can't be installed on any platform. I don't know about macOS but _curses can be installed on Windows and Linux (and presumably any UNIX-based OS). On Windows, Christoph Gohlke's unofficial curses, windows-curses and lot's of libraries allows us to use _curses library. Though I think curses can't be used directly on Windows cmd or powershell. Terminals provided by the Mingw-w64 project, the Cygwin project, etc., most presumably support curses library. WSL terminal also seem to support curses (ncurses). 

So what about a error message like this :-

ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module or migrate to a supported platform.

N.B.: UniCurses library may work with Windows cmd or powershell because it wraps up the PDCurses library on Windows which was developed specifically to work with Windows. Though UniCurses actually can't be used with the Python built-in module curses. We have to specifically import 'unicurses' to use it.

While I wouldn't object to tweaking the message associated with the exception, I'm not sure it's necessary. Googling "curses modulenotfound" gives a number of hits that have good information about the issue. Is there really a practical problem that's being solved here?

"migrate to a supported platform" is almost never practical advice. If we make any change, I'd just say it's not supported on this platform. Or maybe "you may be running on platform that is not supported by curses".

> "migrate to a supported platform" is almost never practical advice. If we make any change, I'd just say it's not supported on this platform. Or maybe "you may be running on platform that is not supported by curses".

Ok...So what about a message like this :-
ModuleNotFoundError: _curses library not found. Install a supported _curses library to use the curses module (The _curses library may not be supported on your platform).

Is this confirmed? If yes then I'll open a PR on https://github.com/python/cpython

Is this issue ready for a PR?

"Install a supported _curses library"

That's not correct advice. _curses is the name of the support module written in C in the Python Standard Library. If it is not available to import in an installation, it's most likely because the build of the module failed because the third-party libraries that implement curses functionality was not installed or not found during the build. How you install the third-party curses library varies greatly by platform or distribution. Some distributions have multiple variants of curses packages, ones with just libraries and others ("-dev" packages) that include header files necessary for Python to build its _curses module.  The Dev Guide has some information on dependencies in general and the details for _curses are in the code in setup.py.  It's also possible that the distributor has broken Python curses support out into a separate package. So it's not easy to provide a message with a useful specific suggestion; there are just too many cases.

I agree with Ned. This is why I'm not sure it’s worth changing the message: googling gives good information, and the exact thing to do in order resolve this (if it’s even possible) is dependent on a number of factors that the code raising the exception can’t know.

Yeah...I agree. Therefore this issue is resolved and I will close this issue now. Thanks everyone for the advice.

With Regards

@shreyanavigyan: Thank you for your efforts to improve Python!