I agree with Jelle. While I have no objections to PEP 675, and while I fully understand that it would be very useful for many Python users, I have no uses for this PEP personally. Using `Literal[str]` to mean "exactly the str type", however, is something I have previously felt the need for (albeit infrequently), and seems like a much more intuitive meaning for the syntax. So while I bear this PEP no ill will, I would also prefer that some other spelling were used, instead of `Literal[str]`. Best, Alex

On 12 Jan 2022, at 19:04, Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:

 It's been a while since this PEP (now PEP 675) was proposed, but I have a piece of feedback: I prefer that we use some other spelling than `Literal[str]`, because the more natural meaning of `Literal[str]` would be "exactly the str type". Currently Literal[] doesn't support types, but I don't want to close the door to adding support in the future, and a use case just came up in https://github.com/python/typing/discussions/1020.

An alternative spelling could be `LiteralOnly[str]`.

...

El mar, 23 nov 2021 a las 20:06, S Pradeep Kumar (<gohanpra@gmail.com>) escribió: Hello all,

We've drafted a PEP to support arbitrary literal string types [1]. Feedback appreciated!

Scala has a very similar concept. See this talk on using Scala's literal string types for "Preventing SQL injection at compile time" [2]

Bikeshedding: We're open to any name that seems easy to understand :)

-- Best, S Pradeep Kumar Graham Bleaney

[1]: https://docs.google.com/document/d/1fbAbA2MCoAcSO1c8gecmUJYZ-Q0utT3CmaXlQ3Ih...

[2]: https://slideslive.com/38907881/literal-types-what-they-are-good-for (slides 52 to 68)

[3]: Previous typing-sig thread: https://mail.python.org/archives/list/typing-sig@python.org/thread/JJWAA5AHZ... _______________________________________________ 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: jelle.zijlstra@gmail.com

---

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: alex.waygood@gmail.com

+1 for this not being a parametrised type. I would suggest StringLiteral, since that's the common term, and further differentiates it from Literal[str] when read aloud. martin On Wed, Jan 12, 2022 at 2:48 PM Graham Bleaney <gbleaney@gmail.com> wrote:

I think a consistent piece of feedback has been that `Literal[str]` has problems, so let's get rid of it. Here are some alternatives that have been suggested by various folks:

- With parameterization: - AnyLiteral[str] - AllLiterals[str] - Literal[str] - LiteralComposed[str] - LiteralConstituents[str] - LiteralDerived[str] - LiteralOnly[str] - MadeFromLiterals[str] - Without parameterization: - AnyLiteralStr or AnyLiteralString - AllLiteralsStr or AllLiteralsString - LiteralStr or LiteralString - LiteralComposedStr or LiteralComposedString - LiteralConstituentsStr or LiteralConstituentsString - LiteralDerivedStr or LiteralDerivedString - LiteralOnlyStr or LiteralOnlyString - MadeFromLiteralStr or MadeFromLiteralString

Pradeep and I would love feedback on which ones a) are good or b) are non-starters

On Wed, 12 Jan 2022 at 15:43, Alex Waygood <alex.waygood@gmail.com> wrote:

...

I agree with Jelle. While I have no objections to PEP 675, and while I fully understand that it would be very useful for many Python users, I have no uses for this PEP personally. Using `Literal[str]` to mean "exactly the str type", however, is something I *have* previously felt the need for (albeit infrequently), and seems like a much more intuitive meaning for the syntax.

So while I bear this PEP no ill will, I would also prefer that some other spelling were used, instead of `Literal[str]`.

Best, Alex

On 12 Jan 2022, at 19:04, Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:

 It's been a while since this PEP (now PEP 675) was proposed, but I have a piece of feedback: I prefer that we use some other spelling than `Literal[str]`, because the more natural meaning of `Literal[str]` would be "exactly the str type". Currently Literal[] doesn't support types, but I don't want to close the door to adding support in the future, and a use case just came up in https://github.com/python/typing/discussions/1020.

An alternative spelling could be `LiteralOnly[str]`.

El mar, 23 nov 2021 a las 20:06, S Pradeep Kumar (<gohanpra@gmail.com>) escribió:

...

Hello all,

We've drafted a PEP to support arbitrary literal string types [1]. Feedback appreciated!

Scala has a very similar concept. See this talk on using Scala's literal string types for "Preventing SQL injection at compile time" [2]

Bikeshedding: We're open to any name that seems easy to understand :)

-- Best, S Pradeep Kumar Graham Bleaney

[1]: https://docs.google.com/document/d/1fbAbA2MCoAcSO1c8gecmUJYZ-Q0utT3CmaXlQ3Ih...

[2]: https://slideslive.com/38907881/literal-types-what-they-are-good-for (slides 52 to 68)

[3]: Previous typing-sig thread: https://mail.python.org/archives/list/typing-sig@python.org/thread/JJWAA5AHZ... _______________________________________________ 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: jelle.zijlstra@gmail.com

_______________________________________________ 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: alex.waygood@gmail.com

-- Thanks, Graham Bleaney _______________________________________________ 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: mdemello@google.com

On Wed, Jan 12, 2022 at 2:52 PM Martin DeMello via Typing-sig <typing-sig@python.org> wrote:

I would suggest StringLiteral, since that's the common term, and further differentiates it from Literal[str] when read aloud.

Except it's a common term for a different thing. In my experience, most languages seem to restrict the "string literal" terminology to mean compile time values that exist in the source code (or at least could be generated by a constant folding pass.) As I understand it, a 675String (not my naming suggestion! just a placeholder :) also includes runtime values that can be assembled from string literals by way of arbitrary runtime computation. I think that's an important distinction, and one that would be muddled by reusing an existing term that typically means something else.

Another bikeshed (to help address the concern that "string literal" implies something visible in source code): KnownString On Sun, 16 Jan 2022 at 12:36, Graham Bleaney <gbleaney@gmail.com> wrote:

I quite like StringLiteral personally, but I understand Andrew's concerns about "string literal" having a very specific meaning. I think something like LiteralDerivedString more clearly captures what we're trying to achieve with this PEP (ie. any string which is composed of literal strings, with allowances for standard string transformations), but it's also unfortunately more wordy. Thoughts on that option?

On Fri, 14 Jan 2022 at 19:16, Andrew Beyer <beyer.andrew@gmail.com> wrote:

...

On Wed, Jan 12, 2022 at 2:52 PM Martin DeMello via Typing-sig <typing-sig@python.org> wrote:

...

I would suggest StringLiteral, since that's the common term, and further differentiates it from Literal[str] when read aloud.

Except it's a common term for a different thing. In my experience, most languages seem to restrict the "string literal" terminology to mean compile time values that exist in the source code (or at least could be generated by a constant folding pass.)

As I understand it, a 675String (not my naming suggestion! just a placeholder :) also includes runtime values that can be assembled from string literals by way of arbitrary runtime computation. I think that's an important distinction, and one that would be muddled by reusing an existing term that typically means something else.

-- Thanks, Graham Bleaney _______________________________________________ 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: hauntsaninja@gmail.com

On Fri, Jan 14, 2022 at 4:16 PM Andrew Beyer <beyer.andrew@gmail.com> wrote:

On Wed, Jan 12, 2022 at 2:52 PM Martin DeMello via Typing-sig <typing-sig@python.org> wrote:

...

I would suggest StringLiteral, since that's the common term, and further differentiates it from Literal[str] when read aloud.

Except it's a common term for a different thing. In my experience, most languages seem to restrict the "string literal" terminology to mean compile time values that exist in the source code (or at least could be generated by a constant folding pass.)

As I understand it, a 675String (not my naming suggestion! just a placeholder :) also includes runtime values that can be assembled from string literals by way of arbitrary runtime computation. I think that's an important distinction, and one that would be muddled by reusing an existing term that typically means something else.

That's a good point. Adding StaticString, ConstantString and SafeString to the mix then. I quite like SafeString because it conveys the intent of the designation, and the exact semantics can be spelt out more clearly in the documentation than in a name. martin

LiteralType[str]? On Thu, 2022-01-13 at 11:28 +0100, Sebastian Rittau wrote:

Am 12.01.22 um 23:47 schrieb Graham Bleaney:

...

I think a consistent piece of feedback has been that `Literal[str]` has problems, so let's get rid of it. Here are some alternatives that have been suggested by various folks: * With parameterization: - AnyLiteral[str]

While I like this name in theory, I would avoid a name containing "Any" for this, since this implies a typing escape hatch.  - Sebastian _______________________________________________ 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: pbryan@anode.ca

Not sure if you're accepting random suggestions from the "crowd" here. If not generic, I would +1 StringLiteral or StrLiteral: If planning to become generic, I would suggest something like. - LiteralOf[str] - LiteralOfType[str] - LiteralFrom[str] - Luis On Thu, Jan 13, 2022 at 2:50 PM Paul Bryan <pbryan@anode.ca> wrote:

TypeLiteral[str]?

On Thu, 2022-01-13 at 06:46 -0800, Paul Bryan wrote:

LiteralType[str]?

On Thu, 2022-01-13 at 11:28 +0100, Sebastian Rittau wrote:

Am 12.01.22 um 23:47 schrieb Graham Bleaney:

I think a consistent piece of feedback has been that `Literal[str]` has problems, so let's get rid of it. Here are some alternatives that have been suggested by various folks:

- With parameterization: - AnyLiteral[str]

While I like this name in theory, I would avoid a name containing "Any" for this, since this implies a typing escape hatch.

- Sebastian _______________________________________________ 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: pbryan@anode.ca

_______________________________________________ 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: pbryan@anode.ca

_______________________________________________ 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: capruce@gmail.com

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. If we want to avoid "safe", how about TrustedStr or TrustedString?

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

Tin, thanks for the feedback. I definitely agree that this is a niche feature and so far the only applications seem to be for security, but I can promise you that it came from a real need we had internally at Meta. We figured the broader Python community could benefit from us standardizing it.

is talking to SQL databases with raw strings so ubiquitous to require a typing PEP?

Most sane frameworks encourage parameterized queries which prevent SQL injection, but there is no guarantee that that parameterized query is actually a string literal. If the string that is *supposed* to be a parameterized query is instead dynamically built with attacker controlled data, you have a potential SQL injection. For example, the Python standard library has the sqlite3 module <https://docs.python.org/3/library/sqlite3.html> which runs raw SQL. Such APIs can be protected from SQL injection using StringLiteral. There are alternative APIs to SQL databases such as ORMs (which prevent the need to run SQL in most common cases), but even they offer escape hatches to run raw SQL (eg. SQLAlchemy offers the execute function <https://docs.sqlalchemy.org/en/14/core/connections.html#sqlalchemy.engine.Co...>). Those escape hatches are another place where StringLiteral should be applied.

as the PEP mentions, no logging frameworks seem to be vulnerable to injection either.

Yet :). As it stands now, the biggest known risk to logging frameworks is DOS (which shouldn't be dismissed outright, but is obviously less severe than most injection attacks) but we don't know that something more severe won't be found down the line. For logging frameworks in particular, LiteralString can provide a bit of protection against a currently known risk as well as future proof against potential future log4j style risks.

The main use case according to the PEP is preventing SQL injection

We just chose SQL injection because it was easy to understand and we wanted a consistent example throughout. We also believe StringLiteral can protect against command injection, cross site scripting, and server side template injection <https://www.python.org/dev/peps/pep-0675/#appendix-a-other-uses>. We could also prevent leaking secrets <https://podalirius.net/en/articles/python-format-string-vulnerabilities/> and (contrived cases of) RCE <https://github.com/gbleaney/python_security/blob/60d2cea66e438fc68a7ff4dd363...> through format strings using StringLiteral, but that didn't make it into the PEP. Arie Bovenberg actually came up with the logging use case <https://bugs.python.org/issue46200> after we submitted this PEP, so I also have hope that others will find use cases for LiteralString that we haven't yet considered. On Tue, Feb 1, 2022 at 2:36 PM Tin Tvrtković <tinchester@gmail.com> wrote:

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

-- Thanks, Graham Bleaney

On Tue, Feb 1, 2022 at 10:50 PM David Foster <davidfstr@gmail.com> wrote:

This proposal is looking really good. Just a few nits from me:

...

# Backwards Compatibility

As PEP 586 mentions, type checkers "should feel free to experiment with more sophisticated inference techniques". So, if the type checker infers a literal string type for an unannotated variable that is initialized with a literal string, the following example should be OK:

``` x = "hello" expect_literal_string(x) # OK, because x is inferred to have type ``Literal["hello"]``. ```

Nit: In this example I don't see how a typechecker could reasonably infer x is of type `Literal["hello"]` when `expect_literal_string` has signature `Callable[[LiteralString], None]`.

Inferring the type for `x` as `Literal["hello"]` after `x = "hello"` is sound. Pyre and Pyright do in fact infer it that way. PEP 586 leaves type checkers free to infer precise literal types as long as it isn't "disruptive":

For example, given the statement x = "blue", should the inferred type of x be str or Literal["blue"]? ... This is not the only viable strategy: type checkers should feel free to experiment with more sophisticated inference techniques. This PEP does not mandate any particular strategy; it only emphasizes the importance of backwards compatibility. -- https://www.python.org/dev/peps/pep-0586/#backwards-compatibility

Note that inferring `Literal["hello"]` does not cause a type error for `expect_literal_string(x)` since `Literal["hello"]` is compatible with the expected type `LiteralString`.

...

# Runtime Behavior We propose an implementation for typing.LiteralString similar to that for typing.Self from PEP 673.

Nit: Would be nice to link the text "PEP 673" to the specific section in that PEP it references: https://www.python.org/dev/peps/pep-0673/#runtime-behavior

New reST syntax was added recently to the PEPs repo to support linking to specific sections of PEPs. Something like: :pep:`PEP 673 <673#runtime-behavior>`

Nit: Since this PEP refers to another PEP within the same Python release (i.e. PEP 673), it should probably add the header field "Requires: 673".

Hmm... this PEP doesn't really depend on that PEP. I can just remove the dependency instead of adding a misleading "Requires" heading.

If you want to mention some more prior art RE marking strings as "safe"/"unsafe" at runtime/statically, Perl has had the concept of "tainted" strings (and other values) for a long time. [2]

Thanks, I'll mention it. (Took me quite a while to understand that Perl man page! Thank goodness we have Python :) ).

[1]:

https://mail.python.org/archives/list/typing-sig@python.org/message/JTO3WKRK... [2]: https://metacpan.org/pod/Taint

-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy

-- S Pradeep Kumar