-
-
Notifications
You must be signed in to change notification settings - Fork 261
Closed
Description
Summary
Contribute type stubs for python-snap7 to the typeshed repository, or verify that the existing inline types (py.typed + type annotations) are properly recognized by all major type checkers and IDEs.
Background
The library already has:
- A
py.typedmarker file (PEP 561) - Full type annotations on public APIs
- Strict mypy compliance
However, publishing to typeshed would ensure that type information is available even when the library is not installed, and would provide broader IDE support.
What needs to be done
- Audit current type annotations for completeness on all public APIs
- Verify that
py.typedis correctly included in the built wheel/sdist - Test type checking works correctly with mypy, pyright, and pytype
- Decide: typeshed contribution vs relying on inline types (PEP 561)
- If inline types are sufficient and working, this may be a no-op
- If there are gaps, either fix inline types or create stubs
- If contributing to typeshed: create stub files following typeshed conventions
- If relying on inline types: ensure
py.typedmarker is in package data in pyproject.toml - Test in VS Code (Pylance) and PyCharm to verify autocomplete and type checking work
- Add CI check that verifies type stubs stay in sync with implementation
References
- PEP 561 — Distributing and Packaging Type Information
- typeshed repository
- mypy documentation on installed packages
Notes
- Since the library already has inline types with
py.typed, the main value of typeshed would be for users who don't have the package installed - Inline types (PEP 561) is generally preferred for actively maintained packages — typeshed is more for third-party stubs of untyped libraries
- The real action item may be: verify everything works end-to-end and fix any gaps
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels