Came here looking for this. I'd been experimenting with custom argument converters and was disappointed to see that they aren't invoked for standard keywords because there are no type hints. Am I correct in assuming that this would correct that?

@twbecker Standard libraries predate all automatic argument conversion support so they needed to implement their own argument conversion. All that custom code can be removed when we add type hints, but that probably doesn't bring any concrete benefits for normal users. Libdoc documentation getting better is nice, though.

In order to get RF 7.3 out soon, I move this issue to RF 7.4 scope. It would still be possible to add type hints to some library or libraries in RF 7.3, though. My plan is to get RF 7.3 release candidate out early next week and that's a deadline for all code changes (which includes annotations). Are there any libraries you'd like to work on in that time frame @robinmackaij? If there are, please submit separate issues for each library and I can add them to RF 7.3 scope.

Are there any libraries you'd like to work on in that time frame @robinmackaij? If there are, please submit separate issues for each library and I can add them to RF 7.3 scope.

I need to work on training-related material at the moment and I also need to work towards an OpenApiTools release, so I have little time to work on this atm. It'd be good to get the sub-issues in the tracker when 7.3 is out, then it's easier to keep track and create the PRs (especially if there's others interested in contributing to this and we need to coordinate on the effort).

Some keywords accepting configuration parameters as **config instead of named-only arguments makes adding type hints to them annoying. The reason to use **config is Python 2 support, so these keywords can be updated. I submitted #5412 about that and try to get it done still in RF 7.3 timeline.