David Mertz, Ph.D. wrote:
My impression whenever this idea is proposed is like Barry's. The "win" isn't big enough not simply to use named functions.
Named functions solve another problem, so I don't see how this is an alternative? More on this below.
Balancing out the slight "win" is the much larger loss of adding additional complexity to the Python language. New grammar, new parser, possibly new semantics if tagged strings are more than exclusively decorative. It's not a *huge* complexity, but it's more than zero, and these keep adding up. Python is SO MUCH less simple than it was when I learned it in 1998. While each individual change might have its independent value, it is now hard to describe Python as a "simple language."
This is an argument against _any_ change to the language. I recognize this sentiment, but stopping all change in the hopes of python being simple again I don't agree with. I don't think the general python developer is there either.
Moreover, there is no reason an editor could not have a capability to "colorize any string passed to a function named foo()." Perhaps with some sort of configuration file that indicates which function names correspond to which languages, but also with presets.
This is an interesting idea. Some counter-arguments: * Anything that's hidden behind a config file won't be used except by very few. So, as you say, you need presets somehow. * Using presents for something simple like html() would render a lot of existing code differently than before this change. I don't think this i acceptable. * The idea that "when a function named X is called, the parameter should be highlighted with language X" seems complicated to implement in a code editor. * Will it apply for all arguments, just the first one, or all strings? Due to the above I think it makes more sense to tag _the string_, not the calling function.
The details could be worked out, and maybe even an informal lexicon could be developed in a shared way. But all we save with more syntax is two character. And the function style is exactly what JavaScript tagged strings do anyway, just as a shorthand for "call a function". Compare: header = html`<h1>Hello</h1>` header = html("<h1>Hello</h1>")
The point here is not saving characters typed, it's tagging a string so it's easy for an editor to highlight it. For the reasons I listed above the two versions above are not equivalent.
If we imagine that your favorite editor does the same colorization inside the wrapped string either way, how are these really different?
If there was a chance this could happen, it would solve my problem nicely. For the reasons above, I don't think this will be acceptable to editors.