Jim Baker has been working on tagged strings, and Guido has a working
implementation. See https://github.com/jimbaker/tagstr/issues/1
I thought Jim had a draft PEP on this somewhere, but I can’t find it.
--
Eric
> On Dec 17, 2022, at 11:14 AM, 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.)
>
> --
> 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/EBCW3OQNASEIRNDETTDWCQYKWWNZXZY5/
Code of Conduct: http://python.org/psf/codeofconduct/
