Repository navigation
Conversation
when users are using the library, they may also want to type-annotate their own code like we do internally, so we should expose the Types they might use for type checking, even if we don't want to expose them for public use.
Owner
|
Thanks a lot for this, @Popaulol! Exposing the types from the package root is a great idea. While testing it against an installed wheel we found the types didn't reach users yet: the package had no #147 builds on your change: it exports the same classes with regular imports listed in |
Leggin
added a commit
that referenced
this pull request
Oct 23, 2026
Re-export the device, attribute, enum and scene classes from the package root and list them in __all__, so users can write `from dirigera import Light` and strict type checkers treat the names as exported. Imports are plain runtime imports rather than TYPE_CHECKING-only, so the same import works when the code runs. Add a py.typed marker (and include it as package data) so type checkers use the library's annotations instead of treating it as untyped. Based on the idea and import list from #146 by @Popaulol. Co-authored-by: Strawberry <56090021+Popaulol@users.noreply.github.com>
Leggin
added a commit
that referenced
this pull request
Oct 23, 2026
Re-export the device, attribute, enum and scene classes from the package root and list them in __all__, so users can write `from dirigera import Light` and strict type checkers treat the names as exported. Imports are plain runtime imports rather than TYPE_CHECKING-only, so the same import works when the code runs. Add a py.typed marker (and include it as package data) so type checkers use the library's annotations instead of treating it as untyped. Based on the idea and import list from #146 by @Popaulol. Co-authored-by: Strawberry <56090021+Popaulol@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
when users are using the library, they may also want to type-annotate their own code like we do internally, so we should expose the Types they might use for type checking, even if we don't want to expose them for public use.
the typing.TYPE_CHECKING ensures that the users can't actually access the classes at runtime.
Although some of these classes, particularly in devices.scene could also be of some legitimate use to some users, for example to create new scenes from their Code.