Accepting PEP 675 - Arbitrary Literal String Type
On behalf of the Python Steering Council, we are accepting PEP 675 - Arbitrary Literal String Type <https://peps.python.org/pep-0675/>. TL;DR - PEP 675 allows type checkers to help prevent bugs allowing attacker-controlled data to be passed to APIs that declare themselves as requiring literal, in-code strings. This is a very thorough PEP with a compelling and highly relevant set of use cases. If I tried to call out all the things we like about it, it’d turn into a table of contents. It is long, but everything has a reason to be there. :) Once implemented, we expect it to be a challenge to tighten widely used existing APIs that accept str today to be LiteralString for practical reasons of what existing code calling unrestricted APIs naturally does. The community would benefit from anyone who attempts to move a widely used existing str API to LiteralString sharing their experiences, successful or not. -gps for the steering council
On 2022-03-21, Gregory P. Smith wrote:
TL;DR - PEP 675 allows type checkers to help prevent bugs allowing attacker-controlled data to be passed to APIs that declare themselves as requiring literal, in-code strings.
Great idea. I did something like this for HTML templating in the Quixote web framework (to avoid XSS bugs). I did it as a special kind of module with a slightly different compiler (using AST transform). With the LiteralString feature, I can implement the same kind of thing directly in Python.
participants (2)
-
Gregory P. Smith -
Neil Schemenauer