Changed enums to conform with proposed change to typing spec discusse…
This is an experiment to understand the potential impact of this change: DO NOT MERGE
Diff from mypy_primer, showing the effect of this PR on open source code:
downforeveryone (https://github.com/rpdelaney/downforeveryone)
+ downforeveryone/isup.py:77:8: error: Non-overlapping equality check (left operand type: "int", right operand type: "EllipsisType") [comparison-overlap]
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
I took a brief look at the remaining errors. The third-party stubtest run still produces a lot of errors, but most look relatively easy to fix. The stdlib stubtest run just complains about a single enum in ssl that may be doing something unusual.
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
I think this PR is now ready for review.
FWIW, this change is blocking the consideration of a change to the typing spec.
This PR is unfortunately still unmergeable for now, due to the pre-commit.ci failures: there are errors in the Ruff and flake8-pyi checks.
The Ruff errors seem to be an obvious bug where Ruff isn't distinguishing between different scopes properly in .pyi files; I'll file an issue with Ruff momentarily.
The flake8-pyi errors are also a bug, but might be hard for us to fix without some ugly hacks at flake8-pyi. (flake8-pyi is maintained by the typeshed team.) Currently, flake8-pyi disallows assignments without annotations in stub files, unless it detects that the assignment is in a class scope in an enum class. But the logic that it uses to detect whether a class is an enum class is pretty crude, due to the fact that flake8-pyi doesn't have access to a semantic model of any kind (it works via very simple analysis of the AST). I can think of some workarounds here for flake8-pyi, but they won't be pretty.
I'm fine with noqa'ing the warnings in the CoersiveEnums. Maybe even do so for the whole file.
I'm fine with noqa'ing the warnings in the
CoersiveEnums. Maybe even do so for the whole file.
Good point, we could easily add an entry to per-file-ignores in our .flake8 file here, rather than making changes over at flake8-pyi. It's an edge case that pretty rarely comes up, after all.
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉
I would like to merge this, regardless of what happens with the proposed spec change, since the change adds strictly more information to the stubs and as far as I can tell no longer regresses anything for mypy users.
cc @AlexWaygood since you added the "DO NOT MERGE" label.
cc @AlexWaygood since you added the "DO NOT MERGE" label.
I added that ages ago because Eric's PR description seemed to indicate that that was what he wanted (the description still says "DO NOT MERGE" in it now). Happy for it to be removed :-)
I agree that overall this PR improves things greatly for users of these stubs, and we should land a version of it regardless of whether the spec changes land. I'm still unsure about one or two of the specific changes — I'll add inline comments shortly
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉