This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients FFY00, p-ganssle, pablogsal, steven.daprano, theacodes, tlalexander, veky
Date 2021-07-13.14:20:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1626186017.28.0.584590580917.issue44603@roundup.psfhosted.org>
In-reply-to
Content
> In fact, you're proposing to use exit as a keyword, but lying about it to the users. If it were really so important, then it _should_ be a keyword, and at least I'd know that I can't use it for my variables anymore. (It's not the first time such a thing would happen. The same thing happened with `async` a few years ago.) But please don't introduce those "keywords just in a particular context", they are horrible from the perspective of usability.

We already have so-called "soft keywords", e.g. `match`, so the horse is out of the barn at this point.

I'm not sure why this is closed as rejected — I don't see any decision one way or the other in this thread or on the PR, did I miss it?

I am struggling to understand how this is a user-hostile change; it is not unreasonable for a REPL to have some commands for interacting with the REPL which are not Python functions. I have accidentally typed `exit` instead of `exit()` many times, and one of the reasons I and many others like IPython is that `exit` exits the REPL. It has never once caused a problem for me, as far as I can tell. I cannot imagine that it is a common scenario for someone to type "exit" in order to inspect the "exit" object — it doesn't even have a useful repr!

The only reason you'd do this would be if you knew what it does and were demonstrating it, or if you were exploring what the various builtins are (which I think is very rare, and you'd probably only have to learn that lesson once).

Vedran's point, however, that you could do `exit = some_func()` and then type `exit` to try and inspect the `exit` object is a solid one. That said, I think we can get around this fairly easily (albeit with the cost of some additional complexity in the "handle the exit keyword" function) — if there's a single AST node that is a name and the name is "exit" or "quit", the REPL inspects locals and globals to see if the object referred to is a Quitter, and if so it exits, otherwise pass through the command as normal (possibly raising a warning like, "Did you mean to exit? You have shadowed the `exit` builtin, so use Ctrl-Z/Ctrl-D to exit or delete your `exit` object and try again").

I understand the arguments for purity and explicability and I'm often one of the first people to argue for keeping things consistent and understandable, but this is one of those things where we could significantly improve user experience for no practical cost. We can identify with very high certainty the situations in which a user intended to exit the REPL, we should go ahead and do it to provide a more intuitive REPL experience.
History
Date User Action Args
2021-07-13 14:20:17p-gansslesetrecipients: + p-ganssle, steven.daprano, veky, pablogsal, FFY00, theacodes, tlalexander
2021-07-13 14:20:17p-gansslesetmessageid: <1626186017.28.0.584590580917.issue44603@roundup.psfhosted.org>
2021-07-13 14:20:17p-gansslelinkissue44603 messages
2021-07-13 14:20:16p-gansslecreate