Skip to content

PEP 675: Minor formatting and wording fixes #2293

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

Merged
AA-Turner merged 1 commit into from
Feb 2, 2022
Merged

PEP 675: Minor formatting and wording fixes #2293

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
17 changes: 8 additions & 9 deletions pep-0675.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -363,13 +363,12 @@ See the examples below to help clarify the above rules:
literal_string: LiteralString = s # Error: Expected LiteralString, got str.
literal_string: LiteralString = "hello" # OK


def expect_literal_string(s: LiteralString) -> None: ...

Addition of literal strings:

::

def expect_literal_string(s: LiteralString) -> None: ...

expect_literal_string("foo" + "bar") # OK
expect_literal_string(literal_string + "bar") # OK
literal_string2: LiteralString
Expand All @@ -387,7 +386,7 @@ Join using literal strings:
xs: List[LiteralString]
expect_literal_string(literal_string.join(xs)) # OK
expect_literal_string(plain_string.join([literal_string, literal_string2]))
# Not OK because the separator has type ``str``.
# Not OK because the separator has type 'str'.

In-place addition using literal strings:

Expand All @@ -409,9 +408,10 @@ Format strings using literal strings:

expect_literal_string(f"hello") # OK

username: str
expect_literal_string(f"hello {username}")
# NOT OK. The format-string is constructed from ``username``,
# which has type ``str``.
# NOT OK. The format-string is constructed from 'username',
# which has type 'str'.

expect_literal_string("hello {}".format(username)) # Not OK

Expand Down Expand Up @@ -542,7 +542,7 @@ string, the following example should be OK:

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

This enables precise type checking of idiomatic SQL query code without
annotating the code at all (as seen in the `Motivation`_ section
Expand Down Expand Up @@ -664,7 +664,6 @@ system, such as ``NewType("SafeSQL", str)``:

SafeSQL = NewType("SafeSQL", str)


def execute(self, sql: SafeSQL, parameters: Iterable[str] = ...) -> Cursor: ...

execute(SafeSQL("SELECT * FROM data WHERE user_id = ?"), user_id) # OK
Expand Down Expand Up @@ -1216,7 +1215,7 @@ since a function may falsely appear to be safe when it is not.

We recommend the following guidelines for using ``LiteralString`` in stubs:

+ If the stub is for a function, we recommend using ``LiteralString``
+ If the stub is for a pure function, we recommend using ``LiteralString``
in the return type of the function or of its overloads only if all
the corresponding arguments have literal types (i.e.,
``LiteralString`` or ``Literal["a", "b"]``).
Expand Down