Great job on the PEP to the authors but it feels a little like a solution in search of a problem.

The main use case according to the PEP is preventing SQL injection, but is talking to SQL databases with raw strings so ubiquitous to require a typing PEP? All systems I've worked with use a library that abstracts that away and you usually build the query somehow other than with strings. And, as the PEP mentions, no logging frameworks seem to be vulnerable to injection either.

That said, it's no concern of mine if folks want to spend their time implementing this but my gut feeling is it won't be all that useful.

On Tue, Feb 1, 2022 at 11:05 PM S Pradeep Kumar <gohanpra@gmail.com> wrote:
Hello all,

We've incorporated a bunch of feedback on the PEP and would like a final round of review from typing-sig.

https://www.python.org/dev/peps/pep-0675/

Main changes:

+ Naming: After all the bikeshedding here over the last two months, there was no undisputed winner :) So, we decided to go with the least bad option: `LiteralString`. We've added a section on Rejected Names along with reasons.
+ Provided an exhaustive list of `str` methods that preserve the literal string type (Appendix C). These would make it seamless for users, e.g., they can use `s.capitalize()` without worrying about losing the literal type of `s`.
+ Described the changes needed in typeshed (Appendix C).
+ Recommended how to use literal string types in type stubs (Appendix D).

If it looks good, we can go forward and submit it to python-dev.

Best,
S Pradeep Kumar
Graham Bleaney

On Tue, Jan 25, 2022 at 7:30 AM David Foster <davidfstr@gmail.com> wrote:
On 1/24/22 2:06 AM, akuviljanen17@gmail.com wrote:
 > What exactly is wrong with SafeStr or SafeString? The whole goal is
to distinguish between arbitrary user input and strings that are known
to be safe, so to me, SafeStr and SafeString are the only suggestions so
far that make sense.

There are other kinds of checks spellable by Python's typing system that
could result in a "safe str". Therefore using the term SafeStr here to
mean a very specific type of "safe str" - specifically a constant
expression - seems misleading to me.

As an example of another type of "safe str", consider the following code:

     Url = NewType('Url', str)

     def parse_url(s: str) -> Url|None:
         if ...:
             return cast(Url, s)
         else:
             return None

     def is_url(s: str) -> TypeGuard[Url]:
         if ...:
             return True
         else:
             return False

Here, "Url" would be a kind of "safe str" type because you could only
generate it through a parsing function. In particular a `str` will not
implicitly convert to an `Url` because it is using a NewType.

--
David Foster | Seattle, WA, USA
Contributor to TypedDict support for mypy
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: gohanpra@gmail.com


--
S Pradeep Kumar
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: tinchester@gmail.com