REPL: exit when the user types exit instead of asking them to explicitly type exit()

[theacodes]

BPO	44603
Nosy	@terryjreedy, @gpshead, @merwok, @stevendaprano, @eryksun, @vedgar, @pganssle, @pablogsal, @asmeurer, @FFY00, @theacodes, @jdevries3133, @tlalexander, @DiddiLeija
PRs	bpo-44603: Exit the interpreter if the user types "exit" #27096

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-07-12.03:15:45.559>
labels = ['type-feature', 'library', '3.11']
title = 'REPL: exit when the user types exit instead of asking them to explicitly type exit()'
updated_at = <Date 2021-10-07.08:08:05.232>
user = 'https://github.com/theacodes'

bugs.python.org fields:

activity = <Date 2021-10-07.08:08:05.232>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-07-12.03:15:45.559>
creator = 'theacodes'
dependencies = []
files = []
hgrepos = []
issue_num = 44603
keywords = ['patch']
message_count = 55.0
messages = ['397273', '397275', '397276', '397293', '397294', '397296', '397297', '397301', '397302', '397305', '397306', '397307', '397308', '397309', '397310', '397311', '397313', '397314', '397315', '397316', '397317', '397331', '397334', '397372', '397373', '397374', '397377', '397379', '397382', '397403', '397404', '397422', '397425', '397427', '397458', '397461', '397462', '397505', '397507', '397512', '397516', '397685', '397691', '397698', '397699', '402590', '402605', '402620', '402623', '402644', '402655', '402664', '402667', '402701', '403359']
nosy_count = 14.0
nosy_names = ['terry.reedy', 'gregory.p.smith', 'eric.araujo', 'steven.daprano', 'eryksun', 'veky', 'p-ganssle', 'pablogsal', 'asmeurer', 'FFY00', 'theacodes', 'jack__d', 'tlalexander', 'DiddiLeija']
pr_nums = ['27096']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue44603'
versions = ['Python 3.11']

[theacodes]

Presently, when using REPL if a user types simply "exit", they are greeted with a message instructing them to do it "correctly":

>>> exit
Use exit() or Ctrl-Z plus Return to exit

It comes across as a little surprising that (1) the program knows what I meant and (2) the program told me it wouldn't do it unless I request it in a very specific way. This isn't very user-friendly behavior.

Further surprising is the inconsistent behavior of the other built-ins described on interpreter start-up. "copyright" and "credits" work fine without being invoked as a function, whereas "help" and "license" rebuff the user.

I know there are compelling technical reasons for the current behavior, however, this behavior is a bit off-putting for newcomers. Knowing the technical reasons behind this behavior made me *more* frustrated than less frustrated.

Python is a lovely language and I think we should do what we can to be friendlier to users. I propose a few changes to fix this specific issue:

(1) Include "exit" in the interpreter startup message, making it: Type "help", "copyright", "credits" or "license" for more information, and type "exit" to quit Python.

(2) Make the interactive interpreter exit when the user types simply "exit" or "quit.

To address some possible edge cases an objections:

• if (2) proves too controversial, we should at least do (1) with the slight modification of "exit" to "exit()".
• if there is a concern about accidentally exiting the interpreter, there are several strategies we can use. First, we can only activate this behavior if, and only if, Python is being used as an interactive interpreter. From what I can tell, main() is already distinguishing this case. Second, if absolutely necessary we could ask the user to confirm that they want to exit. For example:

>>> exit
Are you sure you want to exit Python? (yes/no): 

For what it's worth, I am willing to do this work, however, I might need a little guidance to find the right bits.

[pablogsal]

Thanks, Stargirl for opening this issue and for the thorough description and proposals. I am sympathetic with the idea and the general proposal and (unsurprisingly) I agree with (1).

For (2) there are some challenges here to consider. The most important one is that the mechanism to show those messages is really the repr() of the exit() built-in the one showing the message:

>>> x = exit
>>> repr(x)
'Use exit() or Ctrl-D (i.e. EOF) to exit'

There is no other mechanism in the interpreter that triggers anything when the user inputs that. The most straightforward way is to raise SystemExit from the repr() of the built-in but that has some obvious problems. As printing anything where the exit function lives will also raise SystemExit (for instance printing the builtins module or objects in the GC).

For these reasons I propose to go with (1) with the slight modification of "exit" to "exit()".

[pablogsal]

For reference, this behaviour lives here:

cpython/Lib/_sitebuiltins.py

Lines 13 to 26 in e14d5ae

	class Quitter(object):
	def __init__(self, name, eof):
	self.name = name
	self.eof = eof
	def __repr__(self):
	return 'Use %s() or %s to exit' % (self.name, self.eof)
	def __call__(self, code=None):
	# Shells like IDLE catch the SystemExit, but listen when their
	# stdin wrapper is closed.
	try:
	sys.stdin.close()
	except:
	pass
	raise SystemExit(code)

[vedgar]

Of course, the "license" mention should be changed in the same way (in the same message).

[tlalexander]

Hello all. Curious issue. Thanks Stargirl for opening it.

Would it be possible for the __repr__ function to examine the calling commands and determine if the origin is the special case where exit is typed in the REPL? Then only when Quitter repr is called would the special case be checked. I’m not too familiar with Python internals but I know for example when an exception occurs a stack trace would include information like that. Probably performance of Quitter repr isn’t critical we just don’t want it to have the wrong behavior. But if there’s any way to determine in that call if we’re in this one special case it seems it would be safe to exit.

[pablogsal]

Unfortunately, I don't know how that can help because the stack trace is the same in these two cases:

>>> import traceback
>>> class A:
...   def __repr__(self):
...      traceback.print_stack()

>>> A()
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __repr__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __repr__ returned non-string (type NoneType)

>>> print([A()])
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __repr__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __repr__ returned non-string (type NoneType)

This also becomes a bit tricky if __repr__ is called from C code or from native threads.

In general, the underlying problem is that __repr__ should not have side effects.

[tlalexander]

Makes sense. Thanks for taking a look.

[stevendaprano]

I strongly oppose this change. Merely printing an object should not have a side-effect of this magnitude. Standard Python behaviour is that an object's repr should return a useful string, not exit the interpreter.

This is a backwards-incompatible change: right now, it is perfectly safe to print the builtins namespace in the interactive interpreter:

    vars(builtins)

Doing so gives you are rather large dict, but it is safe and useful. If we make exit actually exit the interpreter instead of print a human readable string, printing the builtins will no longer be safe. It will surprisingly exit in the middle of printing the dict.

exit is not magic syntax, it is an actual object. It exists in the builtins namespace. We can put it in lists, we can introspect it and treat it like any other object.

And most importantly, we can print it and get a useful string.

It is not user-friendly to introduce magical special cases. To call a function, Python always requires parentheses. In the builtins and stdlib there are no special cases of functions that magically perform some task just by trying to view it in the interactive interpreter.

(Of course third party code can do anything. If somebody wants the + operator to exit the interpreter, or len(obj) to erase their hard drive, Python will allow it.)

Making a handful of objects -- help, exit (quit), license -- behave differently to everything else is not user friendly. Consistency is more important than convenience, especially when it comes to something like exit where the side-effect is to exit the interpreter.

What of copyright and credits? I think their design is a mistake, especially copyright. With 11 lines of output, the copyright object seriously uglifies printing the builtins. But at least it doesn't exit the interpreter.

[stevendaprano]

This is a backwards-incompatible change, at the very least it needs an okay from the core devs (and possibly even a PEP) not just a patch.

Stargirl Flowers suggested:

we could ask the user to confirm that they want to exit

Please, no, that is the very opposite of a user-friendly change! If I call exit() in the REPL, I want to exit.

[theacodes]

I don't think we should completely write off the possibility of doing this just because the *current* implementation is counter-intuitive. As I expressed in the original post, the explanation of this behavior is rather unsatisfying to newcomers.

Also @steven.daprano, please do not confuse one recommendation for implementation for the concept.

I agree that printing the Quitter object should not exit the interpreter. However, I disagree that "exit" should not be a special case. Specifically, when using the interactive interpreter the behavior (regardless of implementation strategy) would ideally be:

>>> exit
(interpreter exit)
>>> exit()
(interpreter exit)
>>> print(exit)
Call "exit()" to quit Python. When using the interactive interpreter you can simply type "exit".

This behavior closely matches IPython's behavior, and even a cursory search reveals not only individual users running into this and being frustrated, but even threads where this behavior has reached "meme status": https://twitter.com/0xabad1dea/status/1414204661360472065?s=19

[theacodes]

Also, if a PEP is recommended, I will be happy to author it.