Check untyped defs in the certbot module

[ohemorange]

This issue is for checking untyped definitions in the certbot module.

See explanation here: https://docs.google.com/document/d/1fp0tPP9bzYkUViTnOXAyoT_KfgTfs8HSpNMoU8Tm_SY/edit?usp=sharing

From http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/:

Add the --check-untyped-defs option to your mypy arguments, and get that running with no errors on the codebase. This option causes mypy to check every def in the codebase for internal consistency; mypy can detect many classes of bugs and mistakes in your codebase, without your having written a single type annotation!

In most cases, you’ll want to fix bugs and bad code as you go, but you can also use #type: ignore annotations or exclude files to defer issues. For example, we excluded all of Zulip’s tests at first, since they’re both lower value to type-check and had most of the monkey-patching and other questionable Python in the project. For Zulip, getting clean --check-untyped-defs output took me about 2 days of hard work, including merging fixes for about 40 issues in the Zulip codebase.

I spent another day or two generating nice reproducers for the mypy bugs I’d encountered and improving typeshed. Now that mypy is no longer in its infancy, mypy bugs are increasingly rare. But a large project should expect to encounter and fix typeshed issues (just submit a PR!).

Once mypy --check-untyped-defs passes on your codebase, you should lock down your progress by running the mypy checker in your CI environment.

Because mypy type annotations are optional, once you’ve done the setup above, you can start annotating your codebase at whatever pace you like. Over time, you’ll get the benefits of static types in the parts of the codebase that you’ve annotated, without needing to do anything special to the rest of the codebase (the wonders of gradual typing!). In the next section, I’ll discuss strategy for how to move the codebase towards being fully annotated.

[bmw]

This is being worked on.

There was a question about how to run tests for a single module or single file. To do this, make sure you've activated the virtual environment as described at the bottom of this section.

To run tests on a single package, run pytest --pyargs <module_name>. For instance, run pytest --pyargs certbot to run all unit tests on the certbot module.

To run tests for a single file/module, find the tests for that module and just run python path/to/file_test.py. The convention for where these test files is located is described at the top of https://certbot.eff.org/docs/contributing.html#testing.

[bmw]

FYI, someone is working on this.

[bmw]

When doing this, you should change the acme requirement in setup.py in the root of the repo to acme>0.24.0.

[bmw]

For the set_by_cli.detector usage, I think we should just use # type: ignore and add a link to python/mypy#2087 for now.

[dmfigol]

No zope support yet:
python/mypy#3960

UPD, WA:

    field = interfaces.IConfig.__getitem__(name)  # type: zope.interface.interface.Attribute
    return field.__doc__

[bmw]

Nice digging!

[dmfigol]

certbot/tests/reporter_test.py
we are replacing sys.stdout with six.StringIO()
sys.stdout by default is IO[str]
six.StringIO() is six.StringIO
I haven't found a way to assign the type so that mypy would be happy. Union does not help

[dmfigol]

Submitted PR to fix socket.create_connection type
python/typeshed#2136