-
-
Notifications
You must be signed in to change notification settings - Fork 100
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
Add method annotations (all args and return-values are Any
)
#490
Merged
Conversation
This file contains 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
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Jun 22, 2023
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Jun 22, 2023
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Jun 23, 2023
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Jun 23, 2023
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Jun 24, 2023
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Jun 24, 2023
@vasily-v-ryabov The large amount of changes and using Python's latest type annotation feature. Please feel free to ask questions, and any opinions would be appreciated. |
and move `...Annotator`s from `comtypes/tools/codegenerator.py`
junkmd
added a commit
to junkmd/pywinauto
that referenced
this pull request
Feb 6, 2024
This was referenced Feb 18, 2024
Merged
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.
#400
Type annotations in the codebase of modules generated in the
gen
directory that can be interpreted by the static type checker are defined under theif TYPE_CHECKING:
block.Changes in generated modules
The
IDictionary
in the module generated byGetModule("scrrun.dll")
is defined as shown below.The
Picture
in the module generated byGetModule("stdole2.tlb")
is defined as shown below.Changes in
hints.pyi
I have added a lot of type inference magic tools to
hints.pyi
!The following type information is conveyed to the static type checker by helpers...
property
or_memberspec.named_property
These tools use the functionality of the third-party
typing_extensions
, depending on the version of Python.They are used in the stub file and under the
if TYPE_CHECKING:
block, so NOT need to installtyping_extensions
as runtime prerequisite.Addition of
typeannotator.py
Initially, type annotation stuffs were defined in
codegenerator.py
.However, the amount of codebase I added grew so large that it became difficult to see the changes.
So I decided to add a new module with an appropriate name based on responsibility.
Why all args and return-values are
Any
?Initially, I tried to do detailed type annotations for return values and arguments as well. However, the process of deriving Python-friendly type annotations from
typedesc
would require several hundred additional lines of codebase and possibly refactoring/adding functionality totypedesc
andtlbparser
.I plan to add functionality for more detailed type annotations than
Any
after the1.3.0
release, according to the feedback from the community.Workarounds
Some COM libraries have implementations that are not compatible with the Python language specifications. These include having required arguments that come after optional arguments, using argument names that conflict with reserved words in Python.
Such method definitions causes
SyntaxError
even if under theif TYPE_CHECKING:
block. To prevent those problems, using*args: Any
or**kwargs: Any
instead of using the arguments defined by the COM libraries.# class CLASSNAME_Impl:
commentsSince the beginning of this package, the codebase of the modules generated in the
gen
directory also generates comments, starting with# code template for CLASSNAME implementation
, which would have been there to help with a simple wrapper class implementation.Currently, the mix of comments and type annotations may confuse newcomers.
However, even if there are lack of informations on the behavior of some properties and default arguments, and they are not generated for classes that implement the dispatch method, there may be some projects that rely on the comments to do something.
Therefore, this PR does not eliminate this comment.
The future of the comment should be decided from the community feedback.