https://pantsbuild.org/ logo
Join Slack
Powered by
So every now and then, we get bit by `mypy`'s miss...
# development
b
So every now and then, we get bit by `mypy`'s missing functionality. Currently, it's https://github.com/python/mypy/issues/3135 on my proposal. Conversely, I've only ever been pleasantly happy with 
pyright
. They even add provisional support for draft PRs (like my own!) Do we have a gut feeling on switching the Pants repo to use 
pyright
? In-repo plugins would most likely have to follow-suit
I don't mind trying it out to try and find kinks
p
uhm. My gut reaction is “typescript… eww”. But that’s not a particularly “informed” thought. /shrug
c
I’m in favour, not as an advocate for pyright in particular, but as “anything but mypy” could be worth exploring as a potential improvement.
➕ 1
b
(Funny enough on that discussion, we could not break the plugin API by switching to pyright, see https://github.com/pantsbuild/pants/discussions/19126#discussioncomment-5993245)
h
There is an argument for dogfooding whatever the wider Python user base is more likely to be using, do we have a sense of what that is? Absent a strong sense that it's mypy, I'd be down to switch
b
I'd imagine it's split. Most people likely use mypy in CI, but VSCode uses pyright under the hood (likely why it's so accurate)
So people don't know they're using pyright
h
mypy is a clunky beast. I have no experience with pyright, but it sounds like it's faster and possibly handles more corner cases?
b
Most definitely more correct and errors are good. Runs in typescript which is the weirdness for Pants
h
But also a good thing to dogfood!
b
🙂 I wouldn't mind running both if mypy wouldn't be so buggy 😅
h
We can nudge people towards pyright if we ourselves like it more
But mypy has generally been kind to us, buggy or not
b
I've hit and had to workaround at least a handful of mypy bugs in the pants repo. But I'm also doing type acrobatics half the time 🙃
f
I think running both would be best. Maybe more people would be willing to use pyright if there were more tooling for using it independently of vs code
b
Well in this case, we couldn't use mypy with my changes without an abundance of `# type: ignore`s
p
Does mypy generally wait for PEP approval before merging an implementation?
b
Yeah, pretty much. They wait so good, there likely won't be an implementation for the PEP in mypy for some time after it's approved. See 
dataclass_transform
🤦 1
p
Ouch! That's ugly.
b
I suspect 
mypy
is a symptom of a hand-rolled implementation. Each new interesting thing requires additional special code. I further suspect the more mega-corp type checkers just work on top of some kind of type algebra library, so you really only need ot translate Python types into generic type algebra. But its speculation 🙂
p
I guess the first part of supporting pyright would be adding a pyright backend
b
p
Oh. I didn't see it in the list of subsystems on the 2.17 docs, so I figured we didn't have it yet
b
Yeah weird I suppose it should be there 🤔
p
Well, since pants will manage its own Node install, I guess this should be fine.
b
Yeah, I'm currently looking into the 300 issues it finds 🙂
p
I retract my "eww" response...
😄 2
b
Just wanted to chime in, IME MyPy is more popular because first mover and all, but PyRight is nicer especially in mixed-hinted projects, and used unknowingly by lots too. They both have differences making switching between them a likely wasteful venture, so you would probably pick one at the start of the project and never switch. I would use PyRight more if they even pretended to want to offer other editor integrations! Or if it didn’t require Node to be installed on all dev setups as well
👍 1
Open in Slack
PreviousNext
Powered by