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.
_______________________________________________
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/WCLJ6F6BNXLTH6ZQPWTOKO6OWGAIRO5Z/
Code of Conduct: http://python.org/psf/codeofconduct/
