>>> exit
    Use exit() or Ctrl-Z plus Return to 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.

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

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

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

  $ 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

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.

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.

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.

In fact, on my phone, when I type in just the digits, my phone inserts the parens and dashes. Presumably, users consider this easier to read, and dare I say, more canonical.

So, many applications can't handle phone number input in the exact form they display it to the user.

So you don't actually want the input box to strip dashes, right? It sounds like you want more sites to accept dashes.

You'll probably need to do more than just strip dashes, though. You also need to strip spaces and parenthesis but keep other characters such as + and ~. Many prebuilt phone number input boxes have trouble with even normal American phone numbers, let alone foreign phone number systems. Even if you're only targeting American customers, you'll probably need to support the phone number format for a visiting foreigner as well.

With something as complex as phone numbers I'd just stick to using standard form validation code (like in the HTML standard) to warn users of explicitly invalid input like letters or most special characters and storing phone numbers as a 20 character random text strings for all other purposes. Phone numbers are like time zones, you'd think they're easy to deal with but they're surprisingly finicky to get right.

This works for a lot of other things that people format wildly like Canadian postal codes (which are A1A 1A1 format but many places require presence or absence of a space), credit cards (strip the spaces) and so many other fields.

I agree it should work for any phone number I've ever encountered, but just why

The "best" solution is to separate country code into a different field or input. Then have everything other than the country code (generally called a "subscriber number") added to another input.

Then on the backend you would essentially strip out all the non-numeric characters from the subscriber number and combine the country code and stripped "subscriber number" into an E.164 format number and store that in the database.

(Source) I have spent a decade dealing with phone numbers in databases and web forms. This is the "best" way to handle it, and even it isn't bulletproof, but it works 99.8% of the time. The best way to handle the other 0.2% of cases is to make a descriptive error message that explains to the user how you are expecting them to input their number (ie. No extensions, etc).

Here is the E.164 standard: https://www.itu.int/rec/T-REC-E.164/

Validation with onblur or submission is great, but changing my input makes me angry.

So JavaScript to intercept keypresses or postprocess the string is risky at best and often poorly implemented.

If it was in HTML it could be reliable, and have a unified behaviour when text is pasted in.

For phone numbers there is a "tel" input, so the undesirable behaviour your experiencing may be in spite or because of it.

Personally, I pretty passionate about NOT changing data that my tools receive. It takes a specific, documented situation for me to say "you give me X, and I make it Y". I am more comfortable with "your address, X, has been standardized to Y. Do you accept?".