It looks like you're suggesting hard-coding specific language escape
conventions into f-strings?
What if instead you were to allow delegation to some filter function?
Then, it's generic and extensible.
def html(value: Any):
filtered = ... # filter here
return filtered
f'{!!html}<a href="{url}">...<a>'
Paul
On Sat, 2021-06-26 at 23:19 -0700, Bruce Leban wrote:
> 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
>
>
>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/IJ7DAMTCBJQD5UEAV444DG5GALYN3U6C/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PP7CO35YAAMRGYHXSO5TY5ARW2EWXBBM/
Code of Conduct: http://python.org/psf/codeofconduct/
