Hi Mikhail. I presume that PyCharm already has support for Literal, which was introduced in PEP 586. You can think of LiteralString as "the union of all possible literal strings". Unlike bool and enum literals, you can't feasibly enumerate all possible string literals, so this is conceptual rather than real. It's still a useful concept from the perspective of type checking because you can treat LiteralString just like any other union of string literals. To answer all of your questions above, you can just ask yourself "how do we handle Literal['a', 'b'] in this situation?". The answer should be the same for LiteralString. In pyright, the default inference rules for list expressions always widen literals to their non-literal counterparts. To use your example `xs = ['foo', 'bar']`, pyright infers the type of `xs` as `list[str]`. For more details, refer to https://microsoft.github.io/pyright/#/type-inference?id=literals. Mypy likewise infers `list[str]` in this case. These default inference rules can be overridden through the use of bidirectional type inference (also referred to as an "expected type" or a "type context"). For example, `xs: list[LiteralString] = ['foo', 'bar']` overrides the default type inference rules for list expressions. For more details, refer to https://microsoft.github.io/pyright/#/type-inference?id=bidirectional-type-i.... You also asked about constraint solving for type variables. Pyright's constraint solver does not produce literals unless they are required to meet the constraints. Normally, the solved type is widened to its non-literal counterpart. For example, if you have a function `def func(a: T) -> T: ...`, the expression `func('hi')` evaluates to type `str`, not `Literal['hi']` or `LiteralString`. However, if an additional constraint is present that requires a literal type solution, it will oblige. For example, `x: LiteralString = func("hi")` is fine, and so is `x: Literal['hi', 'bye'] = func("hi")`. Obviously, `x: Literal['bye'] = func("hi")` will produce an error. I'll note that mypy and pyright differ somewhat when it comes to the handling of literals in their constraint solvers. You can read about those differences here: https://microsoft.github.io/pyright/#/mypy-comparison?id=constraint-solver-l.... Apologies if that was more detail than you were looking for. My basic advice for LiteralString is to simply treat it the same as you would any union of Literal strings. -- Eric Traut Author of pyright