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-ide... - 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_l...). 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