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}'.
Python actually already has an “Eyeballs” emoji operator that does exactly that:
>>> print(f"Hello, {'ignore me':0.0}world!")
Hello, world!
The :0.0 “look here” eyeballs emoji indicates that this is for humans to look at, but won’t result in any output in the string.
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
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')}
''''
One note: if PEP 750 is accepted[1], I think it would be possible to define your own tagged string that has built-in comment support.
not obvious that it will be, but possible that some form will exist ↩︎
I do not see any issue. That is how this works. You are not forcing anyone to read nor answer.
I’ll go further than this. Although many Ideas posts don’t end up moving forward, and often involve long discussion, it is not wasted time. The subtleties of language and library design are explored in these threads. It’s one of the ways we spread a shared philosophy of what Python should be.
Other people in the future who have ideas for extending f-strings will be able to see the discussion here and learn from them. They might even have a new idea that neatly addresses the concerns here and ends up with a way to put comments on plain text in f-strings.
No need to apologise. You learned something. We learned something. Everybody wins. That’s what this forum is for, exploring ideas.