Yes, I completely agree. If you want to teach the user the rules, then you follow the rules. The problem with the Python example is that they DID special-case it, but in an unhelpful way.
The special case is actually less a special case than you'd expect. It's "just" a python object that does some slightly funky things when turned into a string[0]. Making plain `exit` actually exit would mean triggering it accidentally could get too easy or would need a special case in the interpreter itself.
It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used.
The regular Python REPL doesn't distinguish between stdout and stderr (perhaps it should!), but you can embed it in things like Jupyter notebooks that do.
> It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used.
That makes sense from a unix tool perspective, but not from a python repl perspective. The repl's behavior is to print the result from the last executed statement. For the exit function, the __repr__ method was overwriten to print the message. That way when you type in "exit", the last value would be exit (the function), and the overwritten __repr__ method causes the help message to be printed. There's no way to have it print to both without adding in some repl specific hacks.
>>> exit
Use exit() or Ctrl-Z plus Return to exit
>>> exit.__repr__()
'Use exit() or Ctrl-Z plus Return to exit'
What if you aren't in the REPL? Using __repr__ at all seems like an abstraction violation. It should be the REPL's job to layer on special casing for exit.
>>> print('%r' % str)
<class 'str'>
>>> def whatisit(x):
... print('It is %r' % x)
...
>>> whatisit(min)
It is <built-in function min>
>>> whatisit(exit)
It is Use exit() or Ctrl-D (i.e. EOF) to exit
Excuse me?
IMO if the REPL wanted a friendly feature like this, it should be a generic REPL feature, not a hack applied to the function exit.
You could use the same pattern as DeprecationWarning. It's suppressed by default and test runners like pytest enable it. A new ReplWarning could be enabled by interactive tools only.
I think I agree though: what you really want to special case is the situation where the user types precisely 'exit<cr>' at a REPL prompt, and that hack needs to exist further up the stack than in the implementation of __repr__.
There would be two ways to implement that, neither of which are particularly good. You could either have the exit function call itself from its __repr__ method, which an abstraction violation so egregious it introduces security vulnerabilities (imagine a logger printing repr(thing) to stderr, and someone sneaking the exit function in there for it to print), or you could special case it by making exit a reserved word, which flies in the face of the Python 3 ethos which changed print from a reserved word to a function and breaks a lot of established code.
Programming languages have rules that the programmer is expected to learn. Part of being a programmer is foregoing a certain amount of user friendliness in favor of an environment that is more powerful so that we can actually get things done. Programmers are paid to memorize and follow these rules so that the end user does not have to learn them.
You're trying to think of problems, not solutions.
It's pretty easy to think of a good solution with few enough downsides that overall the design is much better:
In the REPL only, if you type "exit" and press enter, it quits.
No changes to Python semantics required. All code still works. Much friendlier UX.
I wonder what dubious justification the Python Devs would come up with to avoid implementing that (and therefore admitting they've been wrong for 20 years). They'd probably try and claim it is more confusing to beginners or some nonsense like that.