Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 675: nest sections under Specification #2313

Merged
merged 1 commit into from
Feb 8, 2022
Merged

PEP 675: nest sections under Specification #2313

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 24 additions & 13 deletions pep-0675.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -265,8 +265,24 @@ string type to specify that our API can only accept strings that are
known to be constructed from literals. More specific details follow in
the remaining sections.

Specification
=============


Runtime Behavior
----------------

We propose adding ``LiteralString`` to ``typing.py``, with an
implementation similar to ``typing.NoReturn``.

Note that ``LiteralString`` is a special form used solely for type
checking. There is no expression for which ``type(<expr>)`` will
produce ``LiteralString`` at runtime. So, we do not specify in the
implementation that it is a subclass of ``str``.


Valid Locations for ``LiteralString``
=========================================
-----------------------------------------

``LiteralString`` can be used where any other type can be used:

Expand All @@ -292,12 +308,13 @@ It cannot be nested within unions of ``Literal`` types:


Type Inference
==============
--------------

.. _inferring_literal_string:


Inferring ``LiteralString``
---------------------------
'''''''''''''''''''''''''''

Any literal string type is compatible with ``LiteralString``. For
example, ``x: LiteralString = "foo"`` is valid because ``"foo"`` is
Expand Down Expand Up @@ -350,7 +367,7 @@ Such a refined type in the if-block is also compatible with


Examples
--------
''''''''

See the examples below to help clarify the above rules:

Expand Down Expand Up @@ -456,7 +473,7 @@ Conditional statements and expressions work as expected:


Interaction with TypeVars and Generics
--------------------------------------
''''''''''''''''''''''''''''''''''''''

TypeVars can be bound to ``LiteralString``:

Expand Down Expand Up @@ -502,8 +519,9 @@ Standard containers like ``List`` work as expected:

xs: List[LiteralString] = ["foo", "bar", "baz"]


Interactions with Overloads
---------------------------
'''''''''''''''''''''''''''

Literal strings and overloads do not need to interact in a special
way: the existing rules work fine. ``LiteralString`` can be used as a
Expand Down Expand Up @@ -559,13 +577,6 @@ annotating it as ``x: LiteralString``:
expect_literal_string(x)


Runtime Behavior
================

We propose an implementation for ``typing.LiteralString`` similar to
``typing.NoReturn``.


Rejected Alternatives
=====================

Expand Down