On Wed, Oct 23, 2019 at 1:41 PM Steven D'Aprano <steve@pearwood.info> wrote:
In another comment, you asserted that we all have editors that help
with typing quotes. Don't you have an editor that formats identifiers
differently from string literals?

OK -- but which is it? do we expect people to have smart editors or not? If we do then these are essentially equivalent in ease of reading and writing, and if not, then the new way is easier to write, but harder to read (and frankly, I think harder to write correctly if there is white space in the individual strings.

An example of that: I think it's really handy that  Python allows me to use " as a string delimiter when writing actual text, so I don't have to escape the apostrophe.  (and vice versa for the less common " in the actual string) escaping is a pain and error prone -- and worse when you need to use codes:  "\x20" is at least a bit harder than "\n" -- at least "\n" is a nice mnemonic. And "\u0020 is even worse.

Without an actual study, we are all going with our gut here, but I doubt I'd ever use this except for simple collections of strings that don't have spaces in them. So then there are now Three ways, rather than two obvious ways to do it :-)
 
I predict that even without colour or stylistic hinting, people will
soon get used to the syntax. The fact that space-seperated identifiers
are not legal in Python is a pretty huge hint that these aren't
identifiers.

nor really, because while in a list, you need commas, in regular code, space is (at least conventionally) used to separate identifies and tokens -- that space doesn't scream out at me.
 
Virtually overnight, the Python community got used to the opposite
change, with f-strings: something that looks like a string is actually
code containing identifiers and even arbitrary expressions:

    f"Your score is {score}"

well, it's technically code, yes, but it's functionally still a string -- it looks like a string, and it evaluates to a string. I don't think that's analogous.

> so I don't believe that this will be anywhere near the cognitive load that you state

Again, this is all gut feeling, but we're talking about adding something new here -- a tiny bit better, and maybe worse for some, is NOT enough to add a new feature.

I can't keep track of who's who, but quite amazing to me that this is getting traction, and on the next thread over (some) people seem convinced that

dict1 + dict2 would be incredibly confusing!

oh well, language design is hard.

-CHB

--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython