On: Gmail password first character is case insensitive...

[atoav]

This is like when on a cli application -h displays a hint that you probably meant --help (or the other way around). If you already know someone wants to display the help, why not just display it?

[pansa2 → atoav]

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

[wcoenen → pansa2]

This is different, there is no special case handling here for you typing "exit".

Python functions are invoked with parenthesis, while typing a name without parenthesis retrieves the content of a variable. The Python CLI helpfully sets the "exit" variable to that string so that you don't get a confusing NameError when you make this mistake.

[yatac42 → wcoenen]

If the `exit` variable were set to a string, `exit()` would be an error because you can't use `()` on strings. `exit` is a callable whose `__str__` method returns that message.

Note that this isn't specific to the REPL. Running `print(exit)` in a Python script will print the same message.

[vbezhenar → wcoenen]

It is result of calling `exit.__str__()`. This function could have called exit() itself instead.

[Taywee → vbezhenar]

I'd say that would be much more surprising and unintuitive behavior just for the sake of slightly more convenient REPL use. I wouldn't want stringifying any function to automatically call it. What if you store the function somewhere and print it for debugging, and then have to figure out why your program keeps crashing when you try to just print a list of functions?

Besides, you usually have a more convenient exit available with Ctrl-D anyway.

[richard_todd → Taywee]

Yeah but I can also say it’s a surprise to see instructions on how to exit the REPL when printing a list of functions. Honestly I think there should be no special case, and the REPL should print the “how to exit” text upon startup. As is, the user still has to guess ‘exit’ rather than ‘quit’ ‘abort’ ‘stop’ ‘bye’ etcetera to get the help text. (edit: actually they have the text on 'quit' as well)

[joebob42 → Taywee]

Not for every function, just for exit.

[randallsquared → joebob42]

The surprise is just not worth it.

[klodolph → pansa2]

In Python, it is expected that typing an identifier will not cause an action to happen... so this is consistent with that expectation.

[gertlex → klodolph]

In Python3, that is.

I'd love to find (never looked...) a python3 repl where `print`, `dir`, `help` all behave like python2's `print`, since they're debug/lookup tools. It's rather often I'll open a terminal and want to check one of those things, and... typing () characters just adds significant effort (for lack of better description).

[ufmace → gertlex]

Maybe you want Ruby instead?

I always found Ruby's optional parenthesis to be annoying in stored code, but I gotta admit it's nice on the REPL.

[klodolph → gertlex]

Have you considered ipython? It has commands like that.

[DangitBobby → pansa2]

Notably, the ipython shell does the right thing here. That reason alone warrants an install in most virtual environments in my mind.

[johnchristopher → pansa2]

  $ bc -l
  bc 1.07.1
  Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
  This is free software with ABSOLUTELY NO WARRANTY.
  For details type `warranty'. 
  exit
  0
  quit

Gets me everytime.

[cute_boi → atoav]

sounds like python which don't accept ctrl + c and says you to do ctrl + d or something (i don't know python)

[Freak_NL → cute_boi]

Using Ctrl + D to exit a shell and Ctrl + C to interrupt/break off the current line is a rather strong convention. Bash does this too, and many other REPL's and shells (Ruby's irb for one).

A lot of technical folk who rely on this immediately notice when some shell doesn't do this (exiting instead of breaking of the current input line). I have this with Hbase's hbase shell. I've dropped out of that by accident dozens of times because Ctrl + C interrupts the whole shell.

[xrisk → Freak_NL]

FWIW, Ctrl+D is not "magic". It works because Ctrl+D is EOF. Applications that read input should expect that the input is done when they encounter EOF.

[klodolph → cute_boi]

ctrl + c is accepted, it means "interrupt the current operation", like it does if you are in bash.

If there's no current operation, Python has no way of knowing for sure if you intended to exit, or if you intended to interrupt an operation, but the operation finished before you pressed the key combo.

Python's behavior here is good UX. A key combo that does two different things depending on the current state of the program, and the program's state is changing right in front of you... that would suck.

[tpxl → cute_boi]

I like this feature because I'll use ctrl+C to cancel the current line I'm writing like I would in a terminal. Psql does the same thing, but I started using mysql recently and I keep getting booted out of the app because I want to cancel the current line ):

[dylan604 → atoav]

or just build in both options to getopts

[atoav → dylan604]

This is the way.

[johnchristopher → atoav]

Last time I complained about something like that https://news.ycombinator.com/item?id=27951099 (it's okay to quote myself, right ? I am allowed to ?) I was told it's a UX FEATURE and apparently some people like to be treated like that when interacting with computers. ¯\_(ツ)_/¯

[atoav → johnchristopher]

While I agree with that usage in the example you mentioned in your post over there, I don't think it applies here.

Some applications use -h and some --help. Many support both. So unless we get all software to agree on one standard here, expecting your user to remember which one it was is actually bad UX in my book. Best is to just support both, so people don't have to think about how to get the help.

Displaying a notice when some option changed makes totally sense tho, but -h/--help is not that kind of issue.