My impression whenever this idea is proposed is like Barry's. The "win"
isn't big enough not simply to use named functions.
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."
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. 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>")
If we imagine that your favorite editor does the same colorization inside
the wrapped string either way, how are these really different?
On Sat, Dec 17, 2022 at 12:01 PM Barry Scott <ba...@barrys-emacs.org> wrote:
>
>
> > On 17 Dec 2022, at 16:07, e...@emilstenstrom.se wrote:
> >
> > Hi everyone!
> >
> > I'm the maintainer of a small django library called django-components.
> I've run into a problem that I have a language-level solution (tagged
> strings) to, that I think would benefit the wider python community.
> >
> > *Problem*
> > A component in my library is a combination of python code, html, css and
> javascript. Currently I glue things together with a python file, where you
> put the paths to the html, css and javascript. When run, it brings all of
> the files together into a component. But for small components, having to
> juggle four different files around is cumbersome, so I've started to look
> for a way to put everything related to the component _in the same file_.
> This makes it much easier to work on, understand, and with fewer places to
> make path errors.
> >
> > Example:
> > class Calendar(component.Component):
> > template_string = '<span class="calendar"></span>'
> > css_string = '.calendar { background: pink }'
> > js_string = 'document.getElementsByClassName("calendar)[0].onclick =
> function() { alert("click!") }'
> >
> > Seems simple enough, right? The problem is: There's no syntax
> highlighting in my code editor for the three other languages. This makes
> for a horrible developer experience, where you constantly have to hunt for
> characters inside of strings. You saw the missing quote in js_string right?
> :)
> >
> > If I instead use separate files, I get syntax highlighting and
> auto-completion for each file, because editors set language based on file
> type. But should I really have to choose?
> >
> > *Do we need a python language solution to this?*
> > Could the code editors fix this? There's a long issue thread for vscode
> where this is discussed: https://github.com/Microsoft/vscode/issues/1751
> - The reasoning (reasonable imho) is that this is not something that can be
> done generally, but that it needs to be handled at the python vscode
> extension level. Makes sense.
> >
> > Could the vscode language extension fix this? Well, the language
> extension has no way to know what language it should highlight. If a string
> is HTML or CSS. PyCharm has decided to use a "special python comment" #
> language=html that makes the next string be highlighted in that language.
> >
> > So if just all editors could standardize on that comment, everything
> would work? I guess so, but is that really the most intuitive API to
> standardize around? If the next statement is not a string, what happens? If
> the comment is on the same line as another statement, does it affect that
> line, or the next? What if there's a newline in between the comment in the
> string, does that work?
> >
> > *Suggested solution*
> > I suggest supporting _tagged strings_ in python. They would look like
> html'<span class="calendar"></span>'.
> > * Python should not hold a list of which tagged strings it should
> support, it should be possible to use any tag.
> > * To avoid clashes with current raw strings and unicode strings, a tag
> should be required to be at least 2 characters long (I'm open to other ways
> to avoid this).
> >
> > I like this syntax because:
> > 1. It's clear what string the tag is affecting.
> > 2. It makes sense when you read it, even though you've never seen the
> syntax before.
> > 3. It clearly communicates which language to highlight to code editors,
> since you can use the language identifiers that already exist:
> https://code.visualstudio.com/docs/languages/identifiers#_known-language-identifiers
> - for single letter languages, which are not supported to avoid clash with
> raw strings and unicode strings, the language extension would have to
> support "r-lang" and "c-lang" instead.
> > 4. It mimics the syntax of tagged string templates in javascript (
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates).
> So it has som precedent.
> >
> > (If desirable, I think mimicing javascript further and making tagged
> strings call a function with the tag's name, would be a great addition to
> Python too. This would make the syntax for parsing foreign languages much
> nicer. But this is not required for my specific problem, it's just a nice
> next possible step for this feature.)
> >
> > *Backwards compatibility*
> > This syntax currently raises a invalid syntax error. So introducing this
> shouldn't break existing programs. Python's currently supported string
> types are just single letter, so the suggestion is to require tagged
> strings to be at least two letters.
> >
> > *Feedback?*
> > What are your thoughts on this? Do you see a value in adding tagged
> strings to python? Are there other use-cases where this would be useful?
> Does the suggestion need to support calling tags as functions like in
> javascript to be interesting?
> >
> > (I'm new to python-ideas, so I hope I haven't broken some unspoken rule
> with this suggestion.)
>
> I think this has been discussed before and rejected.
>
> Your need 2 things to happen
> (1) a syntax change in python that is acceptable
> (2) a significant editor to support syntax highlighting for that python
> change.
> (3) someone willing to write and support the feature in the python code
> base
>
> Will you write and support the code?
>
> If the tags are called as functions then you can do it today with this:
>
> def html(s):
> return s
>
> HEAD = html('<head>')
>
>
> Barry
>
> >
> > --
> > Emil Stenström
> > _______________________________________________
> > 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/OXHQHMV2JC2PY7K63VNIMSTP5T46LPKT/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> 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/E27OL43KVTWNH7CDJ7Q7AAHF5UACMWEL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
_______________________________________________
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/SKZNRRJAAT7CNNIYKTJ4YQWJ5PMYV4HJ/
Code of Conduct: http://python.org/psf/codeofconduct/
