Meged master, but tests fail again now.

.gitignore

@@ -12,6 +12,7 @@ docs/build/
 .mypy_cache/
 .incremental_checker_cache.json
 .cache
+.runtest_log.json
 
 # Packages
 *.egg

.travis.yml

@@ -5,7 +5,8 @@ python:
   - "3.4"
   # Specifically request 3.5.1 because we need to be compatible with that.
   - "3.5.1"
-  - "3.6-dev"
+  - "3.6"
+  - "3.7-dev"
   # Pypy build is disabled because it doubles the travis build time, and it rarely fails
   # unless one one of the other builds fails.
   # - "pypy3"
@@ -15,4 +16,5 @@ install:
   - python setup.py install
 
 script:
-  - python runtests.py
+  - python runtests.py -x lint
+  - if [[ $TRAVIS_PYTHON_VERSION == '3.6' ]]; then flake8; fi

CONTRIBUTING.md

@@ -103,6 +103,17 @@ You may also find other pages in the
 helpful in developing your change.
 
 
+Core developer guidelines
+-------------------------
+
+Core developers should follow these rules when processing pull requests:
+
+* Always wait for tests to pass before merging PRs.
+* Use "[Squash and merge](https://github.com/blog/2141-squash-your-commits)"
+  to merge PRs.
+* Delete branches for merged PRs (by core devs pushing to the main repo).
+
+
 Issue-tracker conventions
 -------------------------
 
@@ -111,51 +122,42 @@ to help us track which issues we intend to get to when, and may apply
 labels to carry some other information.  Here's what our milestones
 and labels mean.
 
-### Milestones
+### Task priority and sizing
 
-We use GitHub "milestones" ([see our
-list](https://github.com/python/mypy/milestones)) to roughly order
-what we want to do soon and less soon.
+We use GitHub "labels" ([see our
+list](https://github.com/python/mypy/labels)) to roughly order what we
+want to do soon and less soon.  There's two dimensions taken into
+account: **priority** (does it matter to our users) and **size** (how
+long will it take to complete).
 
-This means they represent a combination of priority and scale of work.
 Bugs that aren't a huge deal but do matter to users and don't seem
-like a lot of work to fix generally go in a near milestone; things
+like a lot of work to fix generally will be dealt with sooner; things
 that will take longer may go further out.
 
-Specifically:
-
-* **Numbered milestones** correspond to releases.  These assignments
-  are changeable, and issues may be moved earlier or later.
-  Assignments to further-out milestones are more likely to
-  change.
-* Point releases, like 0.x.y when we're already at 0.x.z, generally
-  have issues that are less work to tackle and whose user-facing
-  impact is small or a bugfix.  Meatier or more radical issues
-  generally go to a full "minor" release, like 0.x.0.
-* **Future** has other things we don't currently plan to get to anytime
-  soon -- akin to "backlog" in some systems.
-* **Questions** is for issue threads where a user is asking a question
-  but it isn't yet clear that it represents something to actually
-  change.  We use the issue tracker as the preferred venue for such
-  questions, even when they aren't literally issues, to keep down the
-  number of distinct discussion venues anyone needs to track.  These
-  might move to a different milestone if after discussion a bug or
-  feature request emerges.
-* Issues **without a milestone** haven't been triaged.  We aim to
-  triage all new issues promptly, but there are some issues from 2015
-  and earlier that we haven't yet reviewed for triage since adopting
-  these conventions.
-
-### Labels
+We are trying to keep the backlog at a manageable size, an issue that is
+unlikely to be acted upon in foreseeable future is going to be
+respectfully closed.  This doesn't mean the issue is not important, but
+rather reflects the limits of the team.
+
+The **question** label is for issue threads where a user is asking a
+question but it isn't yet clear that it represents something to actually
+change.  We use the issue tracker as the preferred venue for such
+questions, even when they aren't literally issues, to keep down the
+number of distinct discussion venues anyone needs to track.  These might
+evolve into a bug or feature request.
+
+Issues **without a priority or size** haven't been triaged.  We aim to
+triage all new issues promptly, but there are some issues from previous
+years that we haven't yet re-reviewed since adopting these conventions.
+
+### Other labels
 
 * **needs discussion**: This issue needs agreement on some kind of
   design before it makes sense to implement it, and it either doesn't
   yet have a design or doesn't yet have agreement on one.
-* **feature**, **bug**, **refactoring**: These classify the user-facing
-  impact of the change.  Specifically "refactoring" means there should
-  be no user-facing effect.
-* **duplicate**, **wontfix**: These identify issues that we've closed
-  for the respective reasons.
-* **priority**, **question**, **postponed**: These labels predate the
-  milestone conventions and are deprecated; they should be gone on all
-  issues that have been triaged to a milestone.
+* **feature**, **bug**, **crash**, **refactoring**, **documentation**:
+  These classify the user-facing impact of the change.  Specifically
+  "refactoring" means there should be no user-facing effect.
+* **topic-** labels group issues touching a similar aspect of the
+  project, for example PEP 484 compatibility, a specific command-line
+  option or dependency.

MANIFEST.in

@@ -1,3 +1,2 @@
-recursive-include lib-typing *.py
 recursive-include scripts *
 recursive-exclude scripts myunit

README.md

@@ -2,15 +2,16 @@ Mypy: Optional Static Typing for Python
 =======================================
 
 [![Build Status](https://travis-ci.org/python/mypy.svg)](https://travis-ci.org/python/mypy)
-[![Chat at https://gitter.im/python/mypy](https://badges.gitter.im/python/mypy.svg)](https://gitter.im/python/mypy?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) 
+[![Chat at https://gitter.im/python/mypy](https://badges.gitter.im/python/mypy.svg)](https://gitter.im/python/mypy?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 
 
-Got a question? File an issue!
-------------------------------
+Got a question? Join us on Gitter!
+----------------------------------
 
 We don't have a mailing list; but we are always happy to answer
-questions on [gitter chat](https://gitter.im/python/mypy) or filed as
-issues in our trackers:
+questions on [gitter chat](https://gitter.im/python/mypy).  If you are
+sure you've found a bug please search our issue trackers for a
+duplicate before filing a new issue:
 
 - [mypy tracker](https://github.com/python/mypy/issues)
   for mypy isues
@@ -75,17 +76,16 @@ Quick start
 
 Mypy can be installed using pip:
 
-    $ python3 -m pip install -U mypy-lang
-
-*Note that the package name is `mypy-lang`, not `mypy`.*
+    $ python3 -m pip install -U mypy
 
 If you want to run the latest version of the code, you can install from git:
 
     $ python3 -m pip install -U git+git://github.com/python/mypy.git
 
 
 Now, if Python on your system is configured properly (else see
-"Troubleshooting" below), you can type-check a program like this:
+"Troubleshooting" below), you can type-check the [statically typed parts] of a
+program like this:
 
     $ mypy PROGRAM
 
@@ -94,6 +94,8 @@ programs, even if they have type errors:
 
     $ python3 PROGRAM
 
+[statically typed parts]: http://mypy.readthedocs.io/en/latest/basics.html#function-signatures
+
 
 Web site and documentation
 --------------------------
@@ -113,12 +115,11 @@ Troubleshooting
 Depending on your configuration, you may have to run `pip3` like
 this:
 
-    $ python3 -m pip install -U mypy-lang
+    $ python3 -m pip install -U mypy
 
-Double-check that you installed `mypy-lang`, not `mypy`.
-
-Except on Windows, it's best to always use the `--fast-parser`
-option to mypy; this requires installing `typed-ast`:
+This should automatically installed the appropriate version of
+mypy's parser, typed-ast.  If for some reason it does not, you
+can install it manually:
 
     $ python3 -m pip install -U typed-ast
 
@@ -173,6 +174,7 @@ The mypy wiki contains some useful information for contributors:
 
   https://github.com/python/mypy/wiki/Developer-Guides
 
+
 Working with the git version of mypy
 ------------------------------------
 
@@ -187,78 +189,11 @@ whenever you change branches, merge, rebase, or pull.
 
 (It's possible to automate this: Search Google for "git hook update submodule")
 
-Running tests and linting
--------------------------
-
-First install any additional dependencies needed for testing:
-
-    $ python3 -m pip install -U -r test-requirements.txt
-
-To run all tests, run the script `runtests.py` in the mypy repository:
-
-    $ ./runtests.py
-
-Note that some tests will be disabled for older python versions.
-
-This will run all tests, including integration and regression tests,
-and will type check mypy and verify that all stubs are valid.
-
-You can run a subset of test suites by passing positive or negative
-filters:
-
-    $ ./runtests.py lex parse -x lint -x stub
-
-For example, to run unit tests only, which run pretty quickly:
-
-    $ ./runtests.py unit-test pytest
-
-The unit test suites are driven by a mixture of test frameworks:
-mypy's own `myunit` framework, and `pytest`, which we're in the
-process of migrating to.  For finer control over which unit tests are
-run and how, you can run `py.test` or `scripts/myunit` directly, or
-pass inferior arguments via `-a`:
-
-    $ py.test mypy/test/testcheck.py -v -k MethodCall
-    $ ./runtests.py -v 'pytest mypy/test/testcheck' -a -v -a -k -a MethodCall
-
-    $ PYTHONPATH=$PWD scripts/myunit -m mypy.test.testlex -v '*backslash*'
-    $ ./runtests.py mypy.test.testlex -a -v -a '*backslash*'
-
-You can also run the type checker for manual testing without
-installing anything by setting up the Python module search path
-suitably (the lib-typing/3.2 path entry is not needed for Python 3.5
-or when you have manually installed the `typing` module):
-
-    $ export PYTHONPATH=$PWD:$PWD/lib-typing/3.2
-    $ python<version> -m mypy PROGRAM.py
-
-You can add the entry scripts to PATH for a single python3 version:
-
-    $ export PATH=$PWD/scripts
-    $ mypy PROGRAM.py
-
-You can check a module or string instead of a file:
-
-    $ mypy PROGRAM.py
-    $ mypy -m MODULE
-    $ mypy -c 'import MODULE'
-
-To run the linter:
-
-    $ ./runtests.py lint
-
-
-Coverage reports
-----------------
 
-There is an experimental feature to generate coverage reports.  To use
-this feature, you need to `pip install -U lxml`.  This is an extension
-module and requires various library headers to install; on a
-Debian-derived system the command
-  `apt-get install python3-dev libxml2-dev libxslt1-dev`
-may provide the necessary dependencies.
+Tests
+-----
 
-To use the feature, pass e.g. `--txt-report "$(mktemp -d)"`.
+See [Test README.md](test-data/unit/README.md)
 
 
 Development status

appveyor.yml

@@ -0,0 +1,39 @@
+environment:
+  matrix:
+
+    - PYTHON: "C:\\Python35"
+      PYTHON_VERSION: "3.5.1"
+      PYTHON_ARCH: "32"
+
+    - PYTHON: "C:\\Python35-x64"
+      PYTHON_VERSION: "3.5.1"
+      PYTHON_ARCH: "64"
+
+    - PYTHON: "C:\\Python36"
+      PYTHON_VERSION: "3.6.x"
+      PYTHON_ARCH: "32"
+
+    - PYTHON: "C:\\Python36-x64"
+      PYTHON_VERSION: "3.6.x"
+      PYTHON_ARCH: "64"
+
+
+install:
+    - "%PYTHON%\\python.exe -m pip install -r test-requirements.txt"
+    - "git submodule update --init typeshed"
+    - "%PYTHON%\\python.exe setup.py -q install"
+
+build: off
+
+test_script:
+    # Ignore lint (it's run separately below)
+    - "%PYTHON%\\python.exe runtests.py -x lint"
+    - ps: if ($env:PYTHON_VERSION -Match "3.6.x" -And $env:PYTHON_ARCH -Match "64") { iex "$env:PYTHON\\python.exe -m flake8" }
+
+after_test:
+  - "%PYTHON%\\python.exe -m pip install wheel"
+  - "%PYTHON%\\python.exe setup.py bdist_wheel -p win32"
+  - "%PYTHON%\\python.exe setup.py bdist_wheel -p win_amd64"
+
+artifacts:
+  - path: dist\*

build-requirements.txt

@@ -0,0 +1,2 @@
+setuptools
+wheel

conftest.py

@@ -1,4 +1,3 @@
 pytest_plugins = [
     'mypy.test.data',
-    'pytest_cov',
 ]

docs/source/cheat_sheet.rst

@@ -77,6 +77,14 @@ Functions
        # type: (int, float) -> float
        return num1 + my_float
 
+   # An argument can be declared positional-only by giving it a name
+   # starting with two underscores:
+   def quux(__x):
+       # type: (int) -> None
+       pass
+   quux(3)  # Fine
+   quux(__x=3)  # Error
+
    # This is how you annotate a function value.
    x = f # type: Callable[[int, float], float]
 
@@ -157,7 +165,7 @@ that are common in idiomatic Python are standardized.
 
 .. code-block:: python
 
-   from typing import Mapping, MutableMapping, Sequence, Iterator
+   from typing import Mapping, MutableMapping, Sequence, Iterable
 
    # Use Iterable for generic iterables (anything usable in `for`),
    # and Sequence where a sequence (supporting `len` and `__getitem__`) is required.
@@ -187,7 +195,7 @@ Classes
    class MyClass(object):
 
        # For instance methods, omit `self`.
-       def my_class_method(self, num, str1):
+       def my_method(self, num, str1):
            # type: (int, str) -> str
            return num * str1
 

docs/source/cheat_sheet_py3.rst

@@ -73,6 +73,13 @@ Python 3 introduces an annotation syntax for function declarations in `PEP 3107
    def f(num1: int, my_float: float = 3.5) -> float:
        return num1 + my_float
 
+   # An argument can be declared positional-only by giving it a name
+   # starting with two underscores:
+   def quux(__x: int) -> None:
+       pass
+   quux(3)  # Fine
+   quux(__x=3)  # Error
+
    # This is how you annotate a function value.
    x = f # type: Callable[[int, float], float]
 
@@ -174,7 +181,7 @@ Classes
        def __init__(self) -> None:
            ...
        # For instance methods, omit `self`.
-       def my_class_method(self, num: int, str1: str) -> str:
+       def my_method(self, num: int, str1: str) -> str:
            return num * str1