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.)
--
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/
