Skip to content

Fix types and mark as typed #43

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

Merged
merged 4 commits into from
Dec 18, 2022
Merged

Fix types and mark as typed #43

merged 4 commits into from
Dec 18, 2022

Conversation

flying-sheep
Copy link
Contributor

@flying-sheep flying-sheep commented Dec 12, 2022

  1. In order to make pyright/mypy identify this as typed, we need to add a py.typed file.
  2. In order to add ti, we need to convert the module into a package.
  3. In order to keep the __main__ code working, it needs to live in a separate file.

Apart from this, I fixed the types: group_name_formatter, styles, highlights, and usage_markup are ClassVars, not instance variables.

@hamdanal
Copy link
Owner

Thank you for your contribution and sorry I forgot to package the type information.

  1. In order to add ti, we need to convert the module into a package

I would like to keep a single module though. Could you please revert converting the module into a package and I will make a separate PR to include type information in the PyPI distribution for the next release. Thanks

@flying-sheep
Copy link
Contributor Author

I don’t quite understand what you mean.

I think we have two options here

  1. ship an empty file called rich_argparse/py.typed
  2. Change the build system so it creates a rich_argparse.pyi file next to the rich_argparse.py file.
  3. Remember to manually recreate that .pyi file each time you upload a new version.

I think option 1 is by far the simplest

@hamdanal
Copy link
Owner

I don’t quite understand what you mean.

I think we have two options here

  1. ship an empty file called rich_argparse/py.typed
  2. Change the build system so it creates a rich_argparse.pyi file next to the rich_argparse.py file.
  3. Remember to manually recreate that .pyi file each time you upload a new version.

I think option 1 is by far the simplest

Yes option 1 would be the simplest but as I said, I'd like to keep the single-module project. I can create a stub file and tell the build system to always include it in the wheel and sdist. This way the rich_argparse.py file stays and people can still copy it if they want to (it is a viable install option that I use all the time and it is mentioned in the README) and typing users will have their type checking work without complaints from mypy.

In this case if you just keep the fixes for the ClassVar attributes, I can merge this PR and then I can submit another PR with the new packaging and the stub file.

@hamdanal hamdanal merged commit 22951aa into hamdanal:main Dec 18, 2022
@hamdanal
Copy link
Owner

Thank you @flying-sheep for the report and fix. The next release (probably today) will be typed 🚀 .

@flying-sheep flying-sheep deleted the typing branch December 18, 2022 12:37
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 this pull request may close these issues.

2 participants