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
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