Just to be clear on my opinion. I think Emil's idea was 100% appropriate to share on python-ideas, and he does a good job of showing where it works be useful. Sure, a background search is nice, but not required.
That doesn't mean I *support* the idea. I take a very conservative attitude towards language changes. I hope I've provided okay explanation of my non-support, but it's NOT a criticism of Emil in any way. That said, Jim Baker pitched his similar idea to my at last PyCon, and I remember coming closer to feeling supportive. Maybe partially just because I know and like Jim for a long time. But I think he was also suggesting some extra semantics that seemed to move the needle in my mind. On Sat, Dec 17, 2022, 2:27 PM Eric V. Smith via Python-ideas < python-ideas@python.org> wrote: > 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/ >
_______________________________________________ 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/AFSKAMETZPT3IN422N6TMIAIVTBGRAS2/ Code of Conduct: http://python.org/psf/codeofconduct/
