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 mypy roadmap #3460

Merged
merged 1 commit into from
May 26, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 94 additions & 0 deletions ROADMAP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
# Mypy Roadmap

The goal of the roadmap is to document areas the mypy core team is
planning to work on in the future or is currently working on. PRs
targeting these areas are very welcome, but please check first with a
core team member that nobody else is working on the same thing.

**Note:** This doesn’t include everything that the core team will work
on, and everything is subject to change. Near-term plans are likely
more accurate.

## April-June 2017

- Add more comprehensive testing for `--incremental` and `--quick`
modes to improve reliability. At least write more unit tests with
focus on areas that have previously had bugs.
([issue](https://github.com/python/mypy/issues/3455))

- Speed up `--quick` mode to better support million+ line codebases
through some of these:

- Make it possible to use remote caching for incremental cache
files. This would speed up a cold run with no local cache data.
We need to update incremental cache to use hashes to determine
whether files have changes to allow
[sharing cache data](https://github.com/python/mypy/issues/3403).

- See if we can speed up deserialization of incremental cache
files. Initial experiments aren’t very promising though so there
might not be any easy wins left.
([issue](https://github.com/python/mypy/issues/3456))

- Improve support for complex signatures such as `open(fn, 'rb')` and
specific complex decorators such as `contextlib.contextmanager`
through type checker plugins/hooks.
([issue](https://github.com/python/mypy/issues/1240))

- Document basic properties of all type operations used within mypy,
including compatibility, proper subtyping, joins and meets.
([issue](https://github.com/python/mypy/issues/3454))

- Make TypedDict an officially supported mypy feature. This makes it
possible to give precise types for dictionaries that represent JSON
objects, such as `{"path": "/dir/fnam.ext", "size": 1234}`.
([issue](https://github.com/python/mypy/issues/3453))

- Make error messages more useful and informative.
([issue](https://github.com/python/mypy/labels/topic-usability))

- Resolve [#2008](https://github.com/python/mypy/issues/2008) (we are
converging on approach 4).

## July-December 2017

- Invest some effort into systematically filling in missing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you're probably aware, I'm already trying to work on this. My current approach is pretty haphazard, so let me know if you want to coordinate on filling in specific areas.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea we have is to implement an analysis that can help us find the stubs (or parts of stubs) that cause the largest number of Any types when type checking a program. We haven't started work on this yet, but we'll keep you updated once we make some progress on this.

annotations and stubs in typeshed, with focus on features heavily
used at Dropbox. Better support for ORMs will be a separate
project.

- Improve opt-in warnings about `Any` types to make it easier to keep
code free from unwanted `Any` types. For example, warn about using
`list` (instead of `List[x]`) and calling `open` if we can’t infer a
precise return type, or using types imported from ignored modules
(they are implicitly `Any`).

- Add support for protocols and structural subtyping (PEP 544).

- Switch completely to pytest and remove the custom testing framework.
([issue](https://github.com/python/mypy/issues/1673))

- Make it possible to run mypy as a daemon to avoid reprocessing the
entire program on each run. This will improve performance
significantly. Even when using the incremental mode, processing a
large number of files is not cheap.

- Refactor and simplify specific tricky parts of mypy internals, such
as the [conditional type binder](https://github.com/python/mypy/issues/3457),
[symbol tables](https://github.com/python/mypy/issues/3458) or
the various [semantic analysis passes](https://github.com/python/mypy/issues/3459).

- Implement a general type system plugin architecture. It should be
able to support some typical ORM features at least, such as
metaclasses that add methods with automatically inferred signatures
and complex descriptors such as those used by Django models.
([issue](https://github.com/python/mypy/issues/1240))

- Add support for statically typed
[protobufs](https://developers.google.com/protocol-buffers/).

- Provide much faster, reliable interactive feedback through
fine-grained incremental type checking, built on top the daemon
mode.

- Start work on editor plugins and support for selected IDE features.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this roadmap support proposals for addition of items?
I have few such proposals for July-December 2017 section:

And maybe also (for later time?):

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do want to move forward with strict-optional. For the other issues, I'm not sure these warrant roadmap inclusion -- we don't want the roadmap to become synonymous with the issue tracker, and we're not saying we want to ignore the issue tracker.