Still, you intend this as a security check, right? (Quoting your first message: "my_format_string(user_controlled_string, sensitive_data)".) And one could certainly write a taint-clearing function like this (following your identity() example):
Yes, you're right. That's the intention here. Other uses are for readability where we want to insist that the user pass in a literal (`struct.unpack("<I", ...)`).
def clear_or_die(a: str) -> L[str]:
if not verify(a):
raise ValueError(...)
return cast(L[str], a)
As Jelle had pointed out, people already write ad hoc tools to check for literalness. I think the concept of arbitrary literal strings gives us a simple, readable way to express our intentions.
Your examples didn't *quite* show this, but I do think you'd allow this, right?
def f(a: L[str]): ...
def g(a: L[str]):
f(a) # Allowed, even though 'a' isn't a literal -- its type is stil literal
g("hello")
Yes, that's certainly allowed since it's still a literal type. The same goes for `"a" if foo else "b"`, etc. Basically, if `reveal_type()` shows that it's a literal string (either `Literal["hello"]` or `Literal[str]`), it is acceptable.
I do agree with Jelle that the notation Literal[str] feels inconsistent with Literal["hello"].
I agree that it's different from the existing uses in that you can't assign `str` to `Literal[str]`. Open to alternatives. Perhaps something like `LiteralString`? The disadvantages were that:
1. You'd need a separate import for `LiteralString` whereas we can just import the familiar `Literal`.
2. `LiteralString` doesn't show the close relation to `Literal["hello"]` whereas `Literal[str]` does. I read both of them as "literal string" but ymmv.
It's also a straightforward generalization for `Literal[int]`, `Literal[bool]`, etc.
Other options are `Literal[AnyLiteralString]`, but this still requires a separate import and `AnyLiteralString` by itself wouldn't be a valid type, which seems janky.