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