Add type information to TestSuite structure
#4570
Comments
This is enough for Mypy and most likely also to pyright that VSCode uses. Unfortunately PyCharm intellisense is buggy: https://youtrack.jetbrains.com/issue/PY-59658 Related to #4570.
This is enough for Mypy and most likely also to pyright that VSCode uses. Unfortunately PyCharm intellisense is buggy: https://youtrack.jetbrains.com/issue/PY-59658 Related to robotframework#4570. initial type hints Make setter target python 3.8 Add type hints for @Setter usages Fixups tmp dev container.json
This is enough for Mypy and most likely also to pyright that VSCode uses. Unfortunately PyCharm intellisense is buggy: https://youtrack.jetbrains.com/issue/PY-59658 Related to robotframework#4570. initial type hints Make setter target python 3.8 Add type hints for @Setter usages Fixups tmp dev container.json cleanup
This is enough for Mypy and most likely also to pyright that VSCode uses. Unfortunately PyCharm intellisense is buggy: https://youtrack.jetbrains.com/issue/PY-59658 Related to robotframework#4570. initial type hints Make setter target python 3.8 Add type hints for @Setter usages Fixups tmp dev container.json cleanup
|
I added Mypy compatible type hints to our Unfortunately the added typing didn't help at all with PyCharm and I submitted issue PY-59658 about that to their tracker. That issue was closed as a duplicate of PY-29523 and there seemed to be also other related issues. PyCharm also has problems with descriptors being used together with @setter
def source(self, source) -> Path:
return Path(source) if isinstance(source, str) else sourcethen assignment like I'm not surprised with PyCharm having bugs, but it's pretty worrying that both PY-29523 and PY-29770 have been reported already five years ago and there hasn't been much interest towards them. We cannot thus expect them to be fixed in the near future. If you are PyCharm user and interested in better experience when developing Robot Framework or tooling using its APIs, I recommend you to vote the referenced issues. You need to log in to Youtrack to vote, but you can authenticate using your GitHub account. I don't have high hopes for voting to help, but there's not much else we can do. |
1. Use TypeVar also with value passed to the setter methods. I don't like one letter type names T, V, A too much, but that seems to be a convention and it also keeps signature lengths reasonable. 2. Add docstrings. Related to #4570.
ItemList usages need to still be updated to actually get some benefits from this, but quick prototyping indicated that this change along with earlier `setter` enhancements really help with intellisense at least with VSCode. Also add configuration to `.sort()` to be compatible with `list.sort()`.
The base TestSuite ought to now be pretty well typed. Some code used by it was typed at the same time. Also few code changes to ease typing: - TagPattern is now a base class with a factory method, not a factory function. - MultiMatcher.__iter__ yields Matcher objects, not patterns. This is part of #4570.
- ItemList: Accept `Mapping`, not `dict`. - ItemList: Use stringified types instead of `Union` and `List`. - TestSuite: Accept tests and suites as mappings.
Part of #4570. Co-authored-by: serhiy <[email protected]>
Part of #4570. Co-authored-by: serhiy <[email protected]>
- Add typing. Part of #4570. - Enhance `config` to convert values to tuples if original attribute is a tuple. This preserves tuples returned from `to_dict` in `to_json/from_json` roundtrip (#3902). Alternative would be using `@setter` with all attributes containing tuples, but it's easier to handle them here. - Enhance `config` to require attributes to exist. This enhances error reporting.
- Add type hints. Part of #4570. - Make attributes containing normal sequences (i.e. not our custom objects like Tags) explicitly tuples in `__init__`. - Perserve tuples as tuples, instead of converting to lists, also in `to_dict` (related to #3902). That means less work and smaller memory usage. Earlier change to `ModelObject.config` makes sure tuples are preserved over `to_json/from_json` roundtrip. - Use tuples attributes also with `robot.running.model.UserKeyword`. That module will get types and be enhanced in the near future.
Most importantly, use DataDict type alias with `to/from_dict` data.
Typing from the base model still leaks in some places like `TestSuite.tests`. Need to handle that separately with generics or otherwise.
Most importantly makes `create_xxx` methods typing correct with extending classes. Part of #4570. Co-authored-by: serhiy <[email protected]>
Order of arguments passed to `__init__`s were changed so that `parent` is now always last. This affects possible programmatic usage passing argument positionally, but such usage ought to be really rare and its anyway a lot better idea to use keyword arguments when there are this many arguments. Small typing changes also elsewhere.
|
@Serhiy1 and I have been working hard to get proper type hinting to the whole After all the hard work typing now works pretty well. For example, when the following code is opened in VSCode, it shows correct intellisense for all objects: from robot.running import TestSuite as RunningSuite
from robot.result import TestSuite as ResultSuite
s = RunningSuite()
t = s.tests.create()
k = t.body.create_keyword()
s = ResultSuite()
t = s.tests.create()
k = t.body.create_keyword()As I mentioned above, PyCharm unfortunately has issues with typing and intellisense in the above example doesn't work at all. There's not much else we can do that hope they get the biggest issues fixed at some point. After the latest changes @Serhiy1 and I consider Huge thanks for your help @Serhiy1! |
The
TestSuitestructure would benefit from more type hints that would allow IDEs to provide better completion support. That would help with writing code using the visitor API and listener API v3, especially if #4569 and #4568 are implemented.For most parts adding type info ought to be pretty easy and at least those parts should preferably be done already in RF 6.1. It is possible that
TestSuitecode using our@setteris too dynamic to editors to understand and just adding type info to isn't enough. If that's the case, we need to consider changing such code so that it uses the standard@property.setterinstead. That may be too big a task for RF 6.1, though.The text was updated successfully, but these errors were encountered: