[sanderjd]

> Yet the code behind the REPL knows exactly what I was attempting to do and tells me that.

Not really – all the code knows is to stringify objects, and it saw the object called `exit`, for which the stringified version is that error message. But nowhere in that flow does the code know how call anything that could exit the REPL.

/doesn't use Python regularly and thinks the smart move would be to make the REPL understand certain things as commands instead of normal Python code.

[NoGravitas]

Well, the __repr__ method on the 'exit' object is getting called. So that method could actually call sys.exit() and cause repl to exit. But it would be very rude and strange behaviour for calling a __repr__ method to exit the interpreter, or, indeed, to do anything other than return a string representation of the object.

[hyperpape]

What someone more clever than me ought to do is write up a huge investigation of an obscure bug caused by exit.__repr__() calling sys.exit(), and then only at the end comment that it's not real, but could've been if Python went down this road.

[telotortium]

Why? quit and exit are imported exclusively at the REPL: https://docs.python.org/3/library/constants.html?highlight=e.... Would it really be any worse than automatically assigning the result of the last expression to _?

[sanderjd]

Point well made.

[fleitz]

And quit calling exit isn't weird?

[true_religion]

If the REPL initiates an exit via throwing an exception (eg.g new QuitException ) and having the top level of the stack catch it then handle the termination, then you could have the stringification of exit throw that exception too.

It's not really magic at that point. It's not really 'magic' at that point to me.

Granted some people might say its surprising for stringifying an object to call sys.exit() or throw an error that'll cause exiting.... But within the context of the REPL its not surprising.