Fail-fast on missing builtins #14550
Conversation
This comment has been minimized.
This comment has been minimized.
| @@ -16,9 +16,7 @@ m.x # E: "object" has no attribute "x" | |||
| from typing import Dict | |||
| def f(x: Dict[int]) -> None: pass | |||
| [out] | |||
| main:1: error: Module "typing" has no attribute "Dict" | |||
There was a problem hiding this comment.
could you update this test with something more exotic from typing.pyi?
There was a problem hiding this comment.
I can try, but if having dict and list is an invariant now, maybe this test should just go away?
There was a problem hiding this comment.
There are other things in typing.pyi that probably shouldn't be in the default fixture, e.g. like dataclass_transform. This error is still useful there.
(In general, if we can get away with omitting something from the fixture and having devs hit this error, I think that's much more preferable than having an empty class, where degradation from missing API is less obvious. I'm fine with this PR for list and dict, because they're fundamental enough that their complete absence is annoying)
There was a problem hiding this comment.
This leads me to think that maybe the "Maybe your test fixture does not define ..." message should be triggered by attribute access to a type that was defined in a fixture, not only absence of the type.
There was a problem hiding this comment.
In its current state, this test can be removed, and "builtins.list" and "builtins.dict" can be removed from SUGGESTED_TEST_FIXTURES, since we'd no longer have a "trip wire" for devs.
I do think this trip wire can remain useful if we warn about type missing or type's attributes missing, but
a) I can't tell how noisy that'd be
b) Implementing something like this would require determining whether a TypeInfo comes a fixture (or, perhaps, if its defn comes from a fixture). I can't see anything on either of them that allows me to know it right now. Before investing more work, I'm curious what people think.
There was a problem hiding this comment.
Thanks for updating! And sorry my message was confusing, didn't realise there were several other testXMissingFromStubs tests.
I think logic for b) we could use is just checking if module is typing.pyi or builtins.pyi?
…t-on-missing-builtins
…t-on-missing-builtins
This comment has been minimized.
This comment has been minimized.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
As discussed in #14547, some mypy features were degrading rather than failing-fast when certain built-in types (list, dict) were not present in the test environment.
__annotations__) didn't make the culprit (sparse fixture) obvious, making tests harder to debug.For those reasons, I'm suggesting we add
class list: passandclass dict: pass(simplest form without members or type args) to allbuiltinsfixtures. This PR doesn't add specific tests for this, but the assertions in semanal.py should make it painfully obvious.P.S. I agree with @JelleZijlstra that the end goal is not to need those sparse fixtures. I think having mypy code not "work around" sparse fixtures is a good first step.