PEP 750: restrict support for Template + str addition

[davepeck]

• Change is either:
  • To a Draft PEP
  • To an Accepted or Final PEP, with Steering Council approval
  • To fix an editorial issue (markup, typo, link, header, etc)
• PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

Following this PR opened with the steering-council and related discussion, we propose an update to PEP 750 that:

1. Removes support for Template.__radd__ entirely
2. Removes support for str in Template.__add__

A rationale is provided and the two relevant sections of the PEP are updated ("Template String Concatenation" and, in rejected ideas, "Disallowing Template Concatenation").

---

📚 Documentation preview 📚: https://pep-previews--4395.org.readthedocs.build/

[AA-Turner]

Adding the label to prevent inadvertent merging before pronouncement

[dvarrazzo]

I don't know if it shouldn't be more explicit that the str is a literal string, not the result of an f-string expression? See this conversation:

sql_string = t"SELECT id,name "
                   t"FROM users "
                   f"WHERE name={col}"  # 1-chart typo causing injection

[davepeck]

The intent was to continue to allow t"" f"". We should definitely explicitly mention it in the PEP edit.

As mentioned in Python discuss, either we keep both t"" "" and t"" f"" implicit concatenation, or we drop both.

The proposed change to the PEP keeps them, with the view that t"" "" is plausibly useful, and t"" f"" is both rare and trivially lintable. It also acknowledges that there may be real implementation risk in removing some kinds of implicit concat while retaining others (aka ”” f”” should continue to work) — risk that may simply be beyond what is acceptable at this late stage.

An argument to instead drop both forms of implicit concatenation would be: "hey, why should any form of literal construction of t-strings, no matter how uncommon, lead to a plausible injection?"