Hacker News Reader

Comment by mrblampo | Hacker News Reader

First example seems odd? The author acknowledges that the two proposed alternatives (printing "<function exit>" or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do.

View on HN

I'd have done both the hint and the actual result. Like this:

    >>> print
    <built-in function print>
    >>> exit
    <built-in function exit>
    Hint: Use exit() or Ctrl-D (i.e. EOF) to exit
    >>>

This way, it does do the thing you literally asked for, but also does help a newbie out.

> does help a newbie out

… or a long-time dev that switches languages fairly often :)

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'

How about

    def __repr__(self):
        import warnings
        warnings.warn("Use exit() or Ctrl-Z plus Return to exit")
        return super().repr()

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.

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__.

The actual behavior is indeed a bit ridiculous:

    >>> 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.

Also a bit funny:

    >>> def get_function():
    ...     return exit
    ... 
    >>> a = get_function()
    >>> a
    Use exit() or Ctrl-D (i.e. EOF) to exit

Thanks for this, it never occurred to me it used __repr__ for the message. I just added this to my .pythonrc

    exit.__class__.__repr__ = lambda _: exit()
    quit = exit

Edit, you also need this in your bashrc:

    export PYTHONSTARTUP=~/.pythonrc

But really it should just exit. There's really no reason why it shouldn't.

I think telnet does something stupid along the same lines "I know you want to quit but please ask address me as Sir first".

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.

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.

How is it unhelpful? It literally tells what to do.

Is it too hard to write exit() or press Ctrl+D after having incorrectly entered exit?

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.

[0] https://github.com/Source-Python-Dev-Team/Source.Python/blob...

Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos.

When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.

Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.

How do you feel about java/c++ compiler that give hints like "missing semicolon"? Clearly it knows what's wrong. Why not automagically fix that for you[1]?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

JavaScript automatic semicolon insertion does a great job most of the time, but still leads to bafflement when code like

    const b = 1
    [1, 2, 3].forEach(console.log)

(from your linked page) does the wrong thing, because both forms (with and without a semicolon) are syntactically valid. I would much rather just always use semicolons (or, like Python, never use them) than have to memorise the 5% of oddball cases where I need to add them manually to resolve ambiguity.

I'd actually love that feature!

We have AI now that can write the entire code for you. Surely it's not much to ask that a compiler, as it parses your code and likely already has high confidence you need a semicolon in a certain spot, can just correct it for you and move on. Maybe have a --fix-errors option to the compiler command line or something.

Except they didn't -- the result of a statement is turned into a string, and the string is printed. There are standard ways of turning objects into strings, and the `__repr__` function on the `exit` object returns that string. If you call that object then it raises an exception that triggers a REPL to cleanly quit.

The code is here: https://github.com/python/cpython/blob/3.12/Lib/_sitebuiltin...

How about making `exit.__repr__` raise a CleanExit exception that gets caught in the outer REPL and then exits?

I'm fairly sure that having any object's `__repr__` throw an exception and exit would lead to even more confusion. Especially if it exits cleanly.

The object shouldn't be in scope anywhere other than the REPL, but that doesn't mean that something, somewhere, isn't stringifying everything because $REASONS and changing the behaviour won't cause an obscure "crash" somewhere unexpected and hard to debug.

If it actually exited, you might incorrectly conclude that exit would work the same way in a script.

> A world where that's the standard would be chaos.

We saw this play it with web browsers in the late 90s early ‘aughts where they’d do their best to render what they thought you meant if your html was wrong, and it was indeed chaos.

Strict systems with strict inputs makes for a better overall ecosystem.

> The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier.

I agree; Python is actually helping you out here, since just typing `exit` doesn't actually call the callable.

Also, Python being Python, while not recommended, there's nothing stopping the user from assigning to `exit` then printing it in the repl:

    >>> exit = 42
    >>> exit
    42

What would the author expect Python to do in this instance?

I think the current behavior is worse simply exiting. The only concern with exiting when the user types "exit" is that perhaps the user actually wanted to see the value of the `exit` function. But the current behavior doesn't show the value of the `exit` function either, so it's useless for that use case.

Yeah, and it’s also useful to teach newbies about the usual syntax for doing things rather than introducing special-case magic. It would be _weird_ to just quit after writing a bare “exit”.

ipython intentionally diverges from the regular python REPL. It just quits like you expect without crying about it.

Vim iirc has a similar hint telling you to exit when you try something that should exit. I don't remember how it's triggered, ctrl-q maybe (edit, ctrl-c). I see the point, if you know what someone is trying to do, better to just do it, or ignore it, not give a condescending "nudge". Though personally the hint doesn't bother me.

Reply on news.ycombinator.com