Python itself has a habit of contributing to this long history of extremely hostile messages.
If run in interactive mode, the Python interpreter takes its cues from vi and deliberately frustrates the obvious methods to quit. Ctrl-C results in Python whining KeyboardInterrupt but doing nothing helpful. Typing 'exit' or 'quit' both result in messages that make it clear that the interpreter knows what you want to do but won't comply out of spite.
More fun can be had with certain versions of Python 3 when running on Windows, where the Python print function would throw an exception if told to print Unicode characters. This made printing to the console non-portable because Unicode characters had to be stripped if running under Windows. This seems to have been fixed, however.
Still existing are the misleading warnings that Python produces if you forget to include the self parameter on a class method. Python emits an error that blames code that calls the method for passing one too many parameters instead of identifying the underlying problem. Python also gets similarly unhappy, and points fingers at the wrong code, if the brackets are omitted when instantiating a class.
Since Python is dynamically typed, these errors can't be identified until execution. Requiring all-paths testing to catch syntax errors is a special kind of user hostility in and of itself.
Python is an utterly horrible language and it's deeply unfortunate that it has become so popular when so many less error-prone, less obnoxious, alternatives exist.
> Typing 'exit' or 'quit' both result in messages that make it clear that the interpreter knows what you want to do but won't comply out of spite.
The interpreter knows no such thing. Both quit and exit are regular python objects that implement a __repr__ method, both of which return a string that inform the user how to exit. The __repr__ method could have implemented exit, but that would have been poor form (and create issues with tooling), set bad precedent, and go against python coding guidelines.
Ctrl-C giving a keyboard exception rather than exiting is a good thing, as it is far more likely that you are trying to terminate a long running statement, or exit out of sub code block, than trying to kill the interpreter process. This is also the standard behavior of almost any interpreter you care to name (irb, node, clisp, shell). This is because the interpreters try to mimic unix shell semantics (CTRL-D also kills your shell), since they are, after all, shells.
If run in interactive mode, the Python interpreter takes its cues from vi and deliberately frustrates the obvious methods to quit. Ctrl-C results in Python whining KeyboardInterrupt but doing nothing helpful. Typing 'exit' or 'quit' both result in messages that make it clear that the interpreter knows what you want to do but won't comply out of spite.
More fun can be had with certain versions of Python 3 when running on Windows, where the Python print function would throw an exception if told to print Unicode characters. This made printing to the console non-portable because Unicode characters had to be stripped if running under Windows. This seems to have been fixed, however.
Still existing are the misleading warnings that Python produces if you forget to include the self parameter on a class method. Python emits an error that blames code that calls the method for passing one too many parameters instead of identifying the underlying problem. Python also gets similarly unhappy, and points fingers at the wrong code, if the brackets are omitted when instantiating a class.
Since Python is dynamically typed, these errors can't be identified until execution. Requiring all-paths testing to catch syntax errors is a special kind of user hostility in and of itself.
Python is an utterly horrible language and it's deeply unfortunate that it has become so popular when so many less error-prone, less obnoxious, alternatives exist.