Change the exception type and message raised when _curses is not found
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 https://github.com/python/cpython?
On 2021-04-04 at 18:05:12 -0000, Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
BaseException seems, well, wrong to me, and arguably less informational (or worse, misinformational). Why not just improve the error message in the (presumably existing) ModuleNotFoundError? Or create a specialized CursesNotFoundError derived from ModuleNotFoundError?
Ok....A CursesNotFoundError derived from ModuleNotFoundError is ok....Now should a draft PEP be submitted or should a PR be directly submitted to https://github.com/python/cpython?
On 04/04/2021 19:05, Shreyan Avigyan wrote:
I don't think this requires a new exception type. The point about BaseException being a worse choice than ModuleNotFoundError has already been made. The stdlib curses module depends on _curses that may not be present, which is a flaw in my view, and obviously it has taken some research to find the reason. Your complaint is either against the documentation of the curses module (https://docs.python.org/3/library/curses.html#module-curses), for not telling you sooner, or against the text of the curses module itself. The how-to (https://docs.python.org/3/howto/curses.html#curses-howto) does mention the problem and provides pointers to fix it, but incorrectly states that it is the curses module itself that will not be found, not the inner _curses. So that may sow additional confusion. I expect the reasons for this inaccuracy are in the change history. In curses, the author could have wrapped the specific import in try-except to raise a more informative ModuleNotFoundError: try: from _curses import * except ModuleNotFoundError: raise ModuleNotFoundError("_curses! If only this were not a pesky Windows machine!") Or something better you choose. Either the documentation fixes or the code change would make a sensible PR, I think. Or why not addess all three? (It's surely not a PEP.) Jeff Allen
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution?
On Mon, Apr 5, 2021 at 6:41 PM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution?
IMO there's no need to change the type of the exception; ModuleNotFoundError is fine here. Changing the text is a fairly simple thing, so it can be discussed with a simple tracker issue. Any program that attempts to import curses, and has a fallback if that fails, would continue to work correctly after this change. ChrisA (PEP editor)
On Apr 5, 2021, at 4:43 AM, Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution?
There’s no need for a new exception type. What code would catch this new exception? Just update the text of the existing exception, and update the documentation if need be. There’s no need for a PEP. Many, many changes are made without PEPs. Just open an issue on bugs.python.org and create a PR. Eric
Ok....So the text will be changed. I've already used the issue tracker to describe this change. I'm yet to receive confirmation from there. I'll submit the PR as soon as I receive confirmation. Thanks a lot everyone. With Regards
On Mon, Apr 5, 2021 at 7:02 PM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Ok....So the text will be changed.
I've already used the issue tracker to describe this change. I'm yet to receive confirmation from there. I'll submit the PR as soon as I receive confirmation. Thanks a lot everyone.
Sounds like a plan! :) Thanks for helping to improve Python. ChrisA
On 2021-04-04 at 18:05:12 -0000, Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
BaseException seems, well, wrong to me, and arguably less informational (or worse, misinformational). Why not just improve the error message in the (presumably existing) ModuleNotFoundError? Or create a specialized CursesNotFoundError derived from ModuleNotFoundError?
Ok....A CursesNotFoundError derived from ModuleNotFoundError is ok....Now should a draft PEP be submitted or should a PR be directly submitted to https://github.com/python/cpython?
On 04/04/2021 19:05, Shreyan Avigyan wrote:
I don't think this requires a new exception type. The point about BaseException being a worse choice than ModuleNotFoundError has already been made. The stdlib curses module depends on _curses that may not be present, which is a flaw in my view, and obviously it has taken some research to find the reason. Your complaint is either against the documentation of the curses module (https://docs.python.org/3/library/curses.html#module-curses), for not telling you sooner, or against the text of the curses module itself. The how-to (https://docs.python.org/3/howto/curses.html#curses-howto) does mention the problem and provides pointers to fix it, but incorrectly states that it is the curses module itself that will not be found, not the inner _curses. So that may sow additional confusion. I expect the reasons for this inaccuracy are in the change history. In curses, the author could have wrapped the specific import in try-except to raise a more informative ModuleNotFoundError: try: from _curses import * except ModuleNotFoundError: raise ModuleNotFoundError("_curses! If only this were not a pesky Windows machine!") Or something better you choose. Either the documentation fixes or the code change would make a sensible PR, I think. Or why not addess all three? (It's surely not a PEP.) Jeff Allen
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution?
On Mon, Apr 5, 2021 at 6:41 PM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution?
IMO there's no need to change the type of the exception; ModuleNotFoundError is fine here. Changing the text is a fairly simple thing, so it can be discussed with a simple tracker issue. Any program that attempts to import curses, and has a fallback if that fails, would continue to work correctly after this change. ChrisA (PEP editor)
On Apr 5, 2021, at 4:43 AM, Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution?
There’s no need for a new exception type. What code would catch this new exception? Just update the text of the existing exception, and update the documentation if need be. There’s no need for a PEP. Many, many changes are made without PEPs. Just open an issue on bugs.python.org and create a PR. Eric
Ok....So the text will be changed. I've already used the issue tracker to describe this change. I'm yet to receive confirmation from there. I'll submit the PR as soon as I receive confirmation. Thanks a lot everyone. With Regards
On Mon, Apr 5, 2021 at 7:02 PM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Ok....So the text will be changed.
I've already used the issue tracker to describe this change. I'm yet to receive confirmation from there. I'll submit the PR as soon as I receive confirmation. Thanks a lot everyone.
Sounds like a plan! :) Thanks for helping to improve Python. ChrisA
participants (5)
-
2QdxY4RzWzUUiLuE＠potatochowder.com -
Chris Angelico -
Eric V. Smith -
Jeff Allen -
Shreyan Avigyan