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

Support Mypy Type Checking #37

Closed
johnthagen opened this issue Oct 20, 2022 · 6 comments · Fixed by #115
Closed

Support Mypy Type Checking #37

johnthagen opened this issue Oct 20, 2022 · 6 comments · Fixed by #115

Comments

@johnthagen
Copy link
Contributor

johnthagen commented Oct 20, 2022

When adding parsita to a project that is type checked with mypy, we had to add the following configuration to our mypy configuration:

[tool.mypy]
strict = true
disallow_subclassing_any = false

Note that disallow_subclassing_any is not enabled by default, but we use strict = true above to provide better type checking in our Python projects.

Otherwise we get a lot of errors of the form:

 error: Class cannot subclass "TextParsers" (has type "Any")  [misc]

I'm not sure if this is something that can be fixed upstream in parsita, but at a minimum having a type checking page in the documentation with known issues like this could help future users.

Environment

  • Python 3.9
  • parsita 1.7.1
  • mypy 0.982
@drhagen
Copy link
Owner

drhagen commented Oct 20, 2022

Is this a problem because Parsita is not marked as py.typed or is this due to something uniquely weird about Parsita? I just want to know if this can be fixed with something other than full mypy compatibility.

@johnthagen
Copy link
Contributor Author

Good point, I didn't check that parista is missing py.typed. That may solve the issue or possibly reveal other typing issues. That would be the first step to figure out if mypy could be used.

@drhagen
Copy link
Owner

drhagen commented Oct 25, 2022

I took a look at bringing Parsita up to mypy's standards. It is doable, but it's a non-trivial amount of work, and I don't have any experience doing this. To anyone reading this: I would accept a PR to make Parsita mypy compatible.

@johnthagen johnthagen changed the title Document usage with mypy Support Mypy Type Checking Nov 3, 2022
@AndrewMHenry
Copy link

I would add a vote for mypy support. It's easy enough to work around by explicitly suppressing parsita errors, but it would be nice not to need that.

Also, @drhagen, thanks so much for all your work on this library; it's really slick and fun to use!

@drhagen
Copy link
Owner

drhagen commented Sep 30, 2024

I guess I haven't taken a look at this since the release of Parsita 2.0. A lot of things got simplified in the major release, so maybe it will be doable this time around.

@drhagen drhagen mentioned this issue Oct 31, 2024
@drhagen
Copy link
Owner

drhagen commented Nov 21, 2024

After spending a ton of time playing around with Python types in Parsita, I have concluded that it is basically impossible to do well. I have made a best-effort at typing and add py.typed. There are lots of Anys and lots of signatures that are insufficiently specific, but mypy thinks they are all correct now.

Python lacks lower type bounds and higher-kinded types. As such, it is unable to express many of the operations that a parser combinator library must perform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants