PEP 501 was deferred because more learning and time was wanted after introducing f-strings. Now that it has been 5 years, I wonder what the possibilities of revisiting PEP 501 are.
I recently had the experience of using javascript "tagged template literals" and was able to build a SQL string parser that is impossible to have SQL injection with. This is done by having the database connection object only accept a certain type of object, and all sql tagged template literals become that object. Because variables are lazy evaluated, the template function can turn all dynamic inputs into parameters in a SQL query. It is impossible for a dev to accidentally add a user imputed string as a literal.
PEP 501 already mentions how templates (i-strings?) can solve injection. This is a very incredible goal. Injection has been the #1 vulnerability on OWASP for over 10 years, and has been in the top 5 the entire time OWASP has existed (almost 20 years now).
We have an opportunity to completely remove injection attacks.
I won't go through and mention other possibilities of i-strings because the PEP already does an amazing job of doing that.
All recent (within the last two years) discussions of PEP 501 have proposed PEP 501 as a solution to various idea suggested, but then no further discussion on 501 happened. At least, not that I am aware of. If any further discussion of 501 has happened, I would be happy to read up and try to address any concerns.
Some recent discussions were 501 is mentioned:
I would be willing to do any work required to get this PEP improved, but am very new to the PEP process and is what is needed. What is needed to revisit PEP 501, and what can I do to help?