Skip to content

Commit

Permalink
PEP 586: Fix typos and tighten wording (#929)
Browse files Browse the repository at this point in the history
This pull request fixes one or two typos in PEP 586.

It also slightly adjusts the wording of the section on
type inference as suggested here:
Michael0x2a#1 (comment)
  • Loading branch information
Michael0x2a authored and gvanrossum committed Mar 15, 2019
1 parent b870ad2 commit 7370df1
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions pep-0586.rst
Original file line number Diff line number Diff line change
@@ -58,7 +58,7 @@ Note that this problem persists even if we redesign these APIs to
instead accept enums: ``MyEnum.FOO`` and ``MyEnum.BAR`` are both
considered to be of type ``MyEnum``.

Currently, type checkers work around this limitation by adding ad-hoc
Currently, type checkers work around this limitation by adding ad hoc
extensions for important builtins and standard library functions. For
example mypy comes bundled with a plugin that attempts to infer more
precise types for ``open(...)``. While this approach works for standard
@@ -379,7 +379,7 @@ special-casing. For example, programs like the following are type safe::
expects_str(var)

This also means non-Literal expressions in general should not automatically
inferred to be Literal. For example::
be cast to Literal. For example::

def expects_literal(x: Literal["foo"]) -> None: ...

@@ -623,7 +623,7 @@ It's entirely possible we'll circle back and revisit this topic in the future:
we very likely will need some form of dependent typing along with other
extensions like variadic generics to support popular libraries like numpy.

This PEP should be seen as a stepping stones towards this goal,
This PEP should be seen as a stepping stone towards this goal,
rather then an attempt at providing a comprehensive solution.

Adding more concise syntax

0 comments on commit 7370df1

Please sign in to comment.