This is a response in part to Thomas Güttler's "Pre PEP: Python Literals" but I am starting a separate thread because I think it deserves separate discussion, and it's not a direct response to that proposal.

Here's the problem: we want to allow escaping in strings to prevent injection in HTML, SQL, etc.

Proposed solutions generally concentrate on a new kind of escaped format string. I won't go into detail on why I don't like these ideas because others have already covered that ground.

Instead, here's what I think is a better solution: a mechanism to allow formatting with html and sql escaping.

Specifically, I suggest these changes:

(1) Modify string formatting (str.format and f-strings) to add new conversions !html !sql !xml, which escape characters for embedding in html, sql, and xml respectively.**

(2) Modify string formatting to allow these new conversions to be added to the current conversions, e.g. !s!html.

(3) Modify string formatting to add a new syntax that specifies a conversion to use for all subsequent interpolations. The proposed syntax is a replacement_field that starts with two exclamation points. The replacement field itself expands to nothing and only affects the conversion of subsequent fields. Thus

    f"{!!html}<a href='{url}'>{text!r}</a>"

is equivalent to

    f"<a href='{url!html}'>{text!r!html}</a>"

A replacement field of {!!} resets the default conversion.

Yes, this is more typing than t-strings or backticks but EIBTI. And I believe this expands on existing format functions in a way that will be much more clear to someone encountering this new mechanism. And it's more flexible as it allows more granular control of escaping as in this example:

    f"""
    <h1>{title!html}</h1>
    <p>{pre_rendered_html_body}</p>
    """


**It's unclear if there's any functional benefit of having both html and xml encoding other than clarity of usage. Also, it would be nice to have a mechanism for adding additional conversions but I don't want to complicate the discussion at this point. Are there other standard escape mechanisms that would be worth including?

--- Bruce