+1. I would be really surprised if I had something like this:
a = 1
b = 1
f = f"test {a +b}"
t = t"test {a +b}"
and my formatter only formatted the f-string.
Well, one can make up all kind of artificial examples like this. I don’t understand how it’s an argument for t-strings over dedicated tags, or any other kind of syntax actually.
Only allowing t as a prefix means the following example simply doesn’t exist:
import collections
process(collections"a string")
Yes, it’s a silly example, but it’s silly in a new way. Compared to collections(t"a string"), which is already silly. We decided the benefits of allowing this kind of silliness weren’t worth it, because they aren’t really any significant benefit (if you want more details, you’re just going to have to re-read the discussion threads sorry, I’m not rewriting it all).
1 Like
Why would it exist otherwise? That would require the collections module to be callable…
Syntactically it’s correct, even if at runtime it’s determined that it doesn’t work. Whereas t"a string" is syntactically correct and works, and assigning t doesn’t change its behaviour, while collections(...) is left unchanged. So the result is a smaller overall change.
If you want to continue this debate, you should create a new PEP proposing to change it and list out some cases where the benefits are worth it. We discussed it for ages already, and I’m sorry you missed it, but it’s done.
You can also write:
import collections
@collections
def func():
return 5
and by the same token it’s synctatically valid even though it doesn’t work at runtime. Nobody considers that an argument against the decorator syntax.
I wonder if further discussion about this accepted PEP should go into ideas or core development, instead. It seems strange to me to discuss revisions to an already accepted PEP in the PEP discussion.
But to continue this discussion I think the idea of syntactically meaningless tags like proposed above t:re"ab" makes sense as an extension to t-strings.
5 Likes
Well, I was simply trying to understand the reasons why the PEP was designed like this (and then expressing skepticism towards the stated reasons). I certainly do not have enough interest to propose an alternative syntax and implementation.
I like how this can be generalised to all strings and would be great for regexes too: r:re'[0-9]+'.
I agree there are some nice uses for this type of syntax (decimal literals, via r:d’0.0001’, are my favourite example) but this really is off-topic for here. It’s something that was discussed exhaustively (and ultimately rejected) in the original thread for PEP 750 - PEP 750: Tag Strings For Writing Domain-Specific Languages
If people want to revisit that idea, please can it be a new thread under “Ideas” - but please read all the arguments from the thread I linked above, and be prepared to address them. It’s not going to be a good use of anyone’s time to just go over the same questions again, with no new information added.
9 Likes
I agree; any further discussion about syntax alternatives will get split off to a separate topic as off-topic. The PEP itself should have captured why various alternatives weren’t pursued in the end.
I agree it should, but I don’t think it does that convincingly. The Arbitrary String Literal Prefixes section presents three objections that all look like strawmen to me.
- “It was deemed too complex to build in full generality”: you don’t have to build full generality, you can limit the allowed syntax to dotted strings (just like decorators were before PEP 614)
- “It precluded future introduction of new string prefixes”: only if the syntax uses a raw unadorned string prefix. But if the syntax uses e.g.
:my_tag:"Hello {name}", then user-defined tags won’t conflict with any future string prefix - “It seemed to needlessly pollute the namespace”: I don’t even understand that one. “The namespace” is not more polluted than it is by decorators, for example. You can use qualified names if you don’t want to import tags in the current namespace (e.g.
:mylib.my_tag:"Hello {name}").
1 Like
I tried my best to capture the outcome in the PEP, but there’s always room for improvement. If you have suggestions about how I can clarify this section based on the August 2024 discussion thread, that would be very helpful!
Yes, I think the same assumption should apply.
I agree we need to mention this in the docs and possibly should mention it in the PEP itself.
Another asterisk related to expression — not relevant to tools like ruff, but that should probably be called out — is that it captures Python source code if the Template comes from a literal. When developers construct Interpolations at runtime, they can set expression to any arbitrary string.
2 Likes
If there are concerns then maybe it would be good if they were addressed before it is too late.
And to be honest, I would rather have this 1 version late, but be 100% certain that all alternatives were explored thoroughly and we have the best version possible.
Not looked into this enough to have strong opinion, but another point for dedicated syntax could be:
It is likely that t-strings will be used for DSLs.
a = :maybe:"{a}"
would be a bit nicer and indicative than
a = maybe(t"{a}")
1 Like
The SC has approved PEP 750. At this point, it’s part of the language and will be available in Python 3.14. Any new proposals will have to be PEPs (targeting Python 3.15) in their own right.
That precise discussion was had in the thread I quoted above (with slightly different syntax). Unless you can address all of the reasons the idea was rejected previously (and if you can, please do so in a new thread, not here) it’s too late. You may assume the SC is aware of, and agreed with, the reasons the PEP rejected the idea of new string literal syntax.
3 Likes
A general comment for all contributors (not an attack on dg-pb): we’re almost 200 posts into the third[1] megathread on this topic.
If you feel like putting this disclaimer in your post, then the people who have already invested a lot of time in the discussion are probably going to not put a lot of value on your contribution. You’re better off pretending that you have read everything and still want to make the argument.
Possibly second, but I think there was more. Can you blame me for losing count
↩︎
8 Likes
Well, as I said, I’m just not convinced by the three arguments that are given in the PEP (with reasons I stated above), so the PEP could disspell that by better explaining the arguments perhaps.
That’s just not me.
The intent was to support those who have looked into this more than me and are not completely satisfied.
It is great that this has been approved.
But the way I see it, it is only 100% final when it has been released. If there are people who have good arguments and skills, and are willing to invest serious time to make this better, flexibility from SC and everyone involved in this would be highly appreciated.
1 Like