I understand that this use case is pretty rare now, and the situation would be different otherwise. I thought that adding an ignoring format conversion !i or updating docs wold not be a big deal (there is already !a that I never met in the wild), but if not, the most readable solution IMO is @bschubert 's
comment = lambda _: ''
f'''
whatever text {comment('this is a comment')}
'''
that in addition has syntax highlighting out of the box.
I mean that normal strings and f-strings are different regarding this specific feature, because normal strings simply have no syntax for embedding something. And if nothing can be done for normal strings, this can be implemented for f-strings.
Actually, if this is implemented for f-strings, the solution for normal string would be to convert to f- and use this feature.
Just want to be completely clear, as it seems that Iâm not good enough in communicating this idea.
I think youâre being clear, the point is that this difference is a downside to the proposal. Adding extra syntax to one type of strings is going to add confusion, and the benefit is very minimal.
I agree with âminimal benefitâ, but disagree with âconfusionâ. Adding formatting conversion !i will appear in the place where f-strings are already different from normal strings: f'{"comment"!i}'.
The eyeball emoji looks cool.
My initial understanding of the OP was that @michael would like one of these options to be highlighted in the âcomment-colourâ instead of the âstring-colourâ, and that if (for example) {"comment":0.0} makes it into the python documentation thatâs more likely to happen.
For what itâs worth, I think {#comment#} and {"comment":0.0} are the most readable options.
If you would want to turn {"comment":0.0}green instead of red, how would you do that? Is that something your IDE can do already?
Yes, this was the least disruptive option that came to my mind.
This will be different for different IDEs. For Pygments, this is a single line of code, for PyCharm, looks like an enhancement ticket needs to be created and its developers will be responsible for implementation. I doubt that any popular syntax highlighting tool will accept PR for syntax (or convention) not approved by Python community.
I doubt that any workaround-style approach like this will gain sufficient community support to change that. Equally, I donât think a syntax change will happen (as has already been discussed). So I think youâd be better
Finding an IDE/tool than lets you add personal syntax highlighting overrides. I know vim allows this, and a quick search found this, suggesting it should be possible in VS Code. You can create a Pygments plugin that extends the existing Python lexer as you suggest. I donât know about other tools.
Fortunately, the âPython communityâ does not lay down hard and fast rules for how anyone is to write their code, and equally fortunately, the vast majority of syntax highlighters can be tweaked with personal (or per-project) configs. You should be able to abuse the :0.0 formatting directive as a comment (IMO itâs no different from abusing triple-quoted strings as block comments) and match it with a custom formatting directive to make them look like comments.
I personally wonât be doing this, but the optionâs there if you want it.
By the way, if you like the {# comment #} syntax from Jinja2, you can consider actually making the DSL string a Jinja2 template, either as a separate file, in which case there are already IDE plugins/extensions to support Jinja2 syntax highlighting, or as an inline string, in which case you can install samwillisâ Python Inline Source extension for VS Code for syntax highlighting within an embedded Python string.
Looks like this idea has no traction. I appreciate your help, patience and considerateness, although I feel like I wasted a lot of community time; my apologies, I couldnât foresee this.
As for my use case, I ended up with the easiest solution that gives some syntax highlighting:
comment = lambda _: ''
f'''
some text {comment('comment')}
''''