@@ -35,7 +35,8 @@ Here are some potential benefits of mypy-style static typing:
3535 grows, you can adapt tricky application logic to static typing to
3636 help maintenance.
3737
38- See also the `front page <http://www.mypy-lang.org >`_.
38+ See also the `front page <http://www.mypy-lang.org >`_ of the mypy web
39+ site.
3940
4041Would my project benefit from static typing?
4142********************************************
@@ -130,8 +131,8 @@ is a likely feature to be added to mypy in the future, even though we
130131expect that most mypy programs will still primarily use nominal
131132subtyping.
132133
133- I like Python as it is. I don't need static typing.
134- ***************************************************
134+ I like Python and I have no need for static typing
135+ **************************************************
135136
136137That wasn't really a question, was it? Mypy is not aimed at replacing
137138Python. The goal is to give more options for Python programmers, to
@@ -149,10 +150,11 @@ runnable. Also, some Python features and syntax are still not
149150supported by mypy, but this is gradually improving.
150151
151152The obvious difference is the availability of static type
152- checking. The :doc: ` mypy tutorial < tutorial > ` mentions some
153+ checking. The section :ref: ` common_issues ` mentions some
153154modifications to Python code that may be required to make code type
154- check without errors, such as the need to make attributes explicit and
155- more explicit protocol representation.
155+ check without errors. Also, your code must make attributes explicit and
156+ use a explicit protocol representation. For example, you may want to
157+ subclass an Abstract Base Class such as ``typing.Iterable ``.
156158
157159Mypy will support modular, efficient type checking, and this seems to
158160rule out type checking some language features, such as arbitrary
0 commit comments