On Wed, Oct 23, 2019 at 1:41 PM Steven D'Aprano <st...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2FUJRDXBQWQHDV4ZYPPBLICUAUQ67ELQ/
Code of Conduct: http://python.org/psf/codeofconduct/
