Conversation
but overwrite when docstrings annotation exists.
This enables using `# docstub: off` and `# docstub: on` comments – a way to tell docstub to copy wrapped code unchanged into a stub file. Not sure yet how useful this will be, but for now it's self-contained enough and easy to remove. What would be really nice, would be a way to override the output of docstub in a similar manner – in case docstub doesn't do the right thing or doesn't yet know how to. E.g. to handle edge cases like attributes in enums etc.
Apparently, enums members should not include type annotations, instead type checkers are supposed to infer the type from the assigned value itself. Long-term, we might want to support Enums by default, but for no use this not so satisfying workaround.
instead of each method manually. Also makes it possibly to wrap the _docstub_comment_directives decorator and catch errors raised inside it.
The transformer leaves the whitespace untouched, therefore we need to account for that when comparing the output.
Qualnames should be usable in literals as well. E.g., a concrete Enum type.
docstub\._version\..*` Runtime differences with VERSION_TUPLE are picked up for some reason. I couldn't figure out a way to make these go away. docstub\..*\.__match_args__$ Seems to be triggerd by runtime difference in dataclasses docstub._config.Config.__init__ docstub._docstrings.Annotation.__init__ docstub._stubs._Scope.__init__ Likewise dataclasses, specifically related to default values not being included in stubs. docstub._cache.FuncSerializer.__type_params__ Seems to be a runtime difference due to the used generic docstub._cli.main The runtime signature is picked up with *args, **kwargs, probably due to it being a click command
1c10c69 to
93c6542
Compare
Per chance, it worked for the maxos and linux jobs, but not for the windows one. Don't know how `CI_PROJECT_DIR` snuck in, seems like that's the name GitLab would use..
Member
Author
|
Okay, this isn't perfect yet. docstub currently doesn't deal with special cases like enums or dataclasses. mypy.stubtest is also picking up differences with runtime. I'm not sure whether those are false reports. If they are valid, I haven't yet attempted to fix them. Instead I'm Another issue is, that mypy can only use stubs for checking when they are imported. Thus, mypy can't check for correct type usage in docstub itself it seems. But we should already be able to use the stubs to check the test suite. A workaround might be, to use inlined types. E.g. with libcst's apply_type_annotations or retype (no longer maintained). For now this is good enough for a PR. Let's merge. 😊 |
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
1 participant
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.
The goal here is to run docstub on its own codebase and check the resulting stubs with mypy. So far it's been a good way to highlight a few missing features.