-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Meta issue tracker #11201
Comments
There are several meta issue trackers for different topics. Shall we add a |
Yeah, a |
We've finished most of these, thanks in particular to Ivan! I've rolled over the remaining into a new meta issue #16472 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have >1800 open issues, so it's easy to lose sight of ways we could make mypy better. Here's my summary of things I'd like to see.
Related to #6740, since I'd like as many of these as possible to be in a 1.0 release / some of these aren't backwards compatible :-)
UI
Import handling Redesign import handling #8584
Why? We've made a lot of progress from the old days of Import handling is confusing and misleading #4542, but these are probably the most used configuration options and anything we can do to make them less confusing will go a long way.
There's more detail in the linked issue, but tldr; namespace packages by default, improve
ignore-missing-imports
/install-types
/exclude
.edit: A lot of this has been done, see Redesign import handling #8584 (comment) for updated status
Make
check_untyped_defs = True
the default Give an error if there is a variable annotation within a function but no signature #3948 (comment)Why? This is by far the most common stumbling block for users.
Gradual typing is great and we should continue to make it possible, but it's the roaring twenties and maybe we should make the default "mypy will actually check your code".
(The other common gradual typing related change we could make is Proposal: treat "obvious" return type as annotated #4409 / Proposal: infer obvious parameters and return types #10149, but that's harder and maybe more contentious)
Make--no-implicit-optional
the default Turn off implicit-optional by default #9091Fixes
Member access Refactor all member access to go through checkmember.py (meta issue) #7724
Why? Will simplify mypy's code + click the issue to see list of bug reports this will help with.
Function type inference Generic inference regression from #5699 #5738 / Generic decorators don't work with generic functions #1317Why? Use of generic higher order functions is currently pretty broken.
Fix Callable instance variables Cannot assign to field of Callable type #708We had most of a fix for this, but it was reverted in Revert "Fix callable instance variable support (#10548)" #11571
Import cycle crash Assertion error, importing library with typehints #8481Why? This is the unresolved crash that has been reported the most number of times. You can't e.g. really use PyTorch without running into it.
Behaviour changes
These have all been reported dozens of times.
Numbers int is not a Number? #3186 (comment)Why? Understandably, people keep wanting to use
numbers
to type numbers and it doesn't work at all, contradictingisinstance
. I don't know that it's best solvable within mypy (I lean towards introducing lies in typeshed), but we should do something.Default value of generic parameters Unable to specify a default value for a generic parameter #3737 (comment)
Why? It's totally reasonable to want to have generic parameters with defaults and there are paths forward to accomplish this (as also demonstrated by the behaviour of other type checkers).
Always narrow types Types not added to binder on initial assignment #2008 (comment) (proposal 3)
Why? Users find it surprising because it seems obvious that mypy should know the variable is of the narrower type. There was a big discussion in typing-sig and all the type checkers agreed this behaviour was probably the best.
Detect unbound variables Not detecting UnboundLocalError #2400 References to names before they're bound should generate an error (UnboundLocalError) #686Ternary joins Doesn't correctly match overloads when calling method using conditional arguments #9264 / Protocols and
... if ... else ...
#5392 / Constrained TypeVar fails to narrow on left hand side of conditional expression #4134 / Use union instead of join for unifying types #12056Why? Users find it inconsistent that
if-else
behaviour differs from ternary / not sure there's a good reason for mypy's current behaviour. Also brings us in line with other type checkers.Lost narrowing in inner functions Inner method discards type narrowing done in outer method #2608Why? Users are often surprised by Python's behaviour here. In the general case mypy is correct, but given how much this comes up, in specific cases there are things we can do to reduce false positives: Inner method discards type narrowing done in outer method #2608 (comment). We also have bad false negatives here: closured value not narrowed for immediately invoked lambda, but incorrectly narrowed for non-immediately invoked lambda #10993
Features
PEP 612 PEP 612 tracking issue #8645PEP 613 Support PEP 613 #9404PEP 646 Support for PEP 646 #12280match statement Support for python 3.10 match statement #10191Recursive types Support recursive types #731(other maintainers, feel free to edit)
The text was updated successfully, but these errors were encountered: