Skip to content
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.

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

Add type hints to codebase #6742

Open
Eric-Arellano opened this issue Nov 8, 2018 · 2 comments

Comments

2 participants
@Eric-Arellano
Copy link
Contributor

commented Nov 8, 2018

Hello, as discussed via Slack and google group, I'm hoping to set us up with type hints in our codebase (PEP 484). I led a similar project while at Foursquare, and think the scope is achievable.

This wouldn't start until we finish the Python 3 port (#6062).

Why type hints

  • Catch bugs at lint time.
  • Improved documentation.
  • More confidence while refactoring.

Scope

  • Allow any new or refactored code to use type hints.
  • Enforce type safety through CI integration.
  • Add type hints to core code.

This issue does not entail 100% type coverage.

Incremental type safety

Rather than trying to rewrite our entire codebase at once, we'd take a more incremental approach. Core code would be ported so that any dependee has some level of type safety. Over time, we would expect any new code and refactored code to have type hints, leading to an incremental increase in coverage.

This is the approach taken by most organizations, including Foursquare and Dropbox (author of MyPy).

Tasks

  • Setup MyPy config and script as a starting point (#7704)
  • Get MyPy working with no args and start enforcing in CI.
    * Allow liberal skipping of types.
  • Add type hints to some core code, e.g. util.
  • Implement protocols for enum and datatype.
@cosmicexplorer

This comment has been minimized.

Copy link
Contributor

commented Jan 21, 2019

We should absolutely figure out how to represent type hints such as Union[string, bytes] in python docstring syntax as per this comment on #7120. I think we should probably add that to the checklist? The comment mentions a link which describes how python docstring conventions work, but doesn't answer how type hints should.

@cosmicexplorer

This comment has been minimized.

Copy link
Contributor

commented Mar 29, 2019

One additional thought is that if we wanted to look at type hints before we're fully py3-compatible, we could start creating stub files to get most of the benefits before we can put them into the code itself.

Eric-Arellano added a commit that referenced this issue May 14, 2019

Setup MyPy config and enforce types for build-support scripts (#7704)
### Problem
We would like to use type hints throughout our code base, per #6742.

However, we must configure it with sensible defaults to make it easier to use and to provide a consistent interface for developers.

We should also enforce as much type safety as we can via our `pre-commit` check.

### Solution
* Add new `mypy.ini` file with fairly loose defaults that are good for first time codebases. Eventually, we will want to do things like require all functions to be typed, but for now we loosen our expectations.
* Link to the config file in `pants.ini`, along with using the most modern MyPy release which gives us  the `strict_equality` check.
* Run `mypy.py` over the build-support scripts, which are fully typed.
   * Acts as a proof of concept for how this will be integrated into CI.

### Result
`./pants mypy` is now a bit more useful on our codebase, even though it will still fail because of pre-existing issues.

Further, the build-support folder will not have any typing regressions now.

Eric-Arellano added a commit to Eric-Arellano/pants that referenced this issue May 14, 2019

Setup MyPy config and enforce types for build-support scripts (pantsb…
…uild#7704)

### Problem
We would like to use type hints throughout our code base, per pantsbuild#6742.

However, we must configure it with sensible defaults to make it easier to use and to provide a consistent interface for developers.

We should also enforce as much type safety as we can via our `pre-commit` check.

### Solution
* Add new `mypy.ini` file with fairly loose defaults that are good for first time codebases. Eventually, we will want to do things like require all functions to be typed, but for now we loosen our expectations.
* Link to the config file in `pants.ini`, along with using the most modern MyPy release which gives us  the `strict_equality` check.
* Run `mypy.py` over the build-support scripts, which are fully typed.
   * Acts as a proof of concept for how this will be integrated into CI.

### Result
`./pants mypy` is now a bit more useful on our codebase, even though it will still fail because of pre-existing issues.

Further, the build-support folder will not have any typing regressions now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.