Pekka Klärck
Pekka Klärck
Another small problem is handling variables. I believe we should handle the `-tag` syntax when building the executable model and we don't have variables available at that point. It means...
This is a good idea but there are few design decisions to be made: 1. Where to exactly add the information? At the moment the top level `` element has...
One possible way to implement this would be using our current `robot.running.Keyword`. It's already used by `BuiltIn.run_keyword` and it needed to be enhanced to avoid the problems explained in the...
A benefit of using `robot.running.Keyword` that was discussed above is that we already have it and it is part of the public API. A problem is that it actually represents...
In addition to having model objects representing actual keywords, not keyword calls, under `robot.running`, also `robot.libdocpkg` implementing Libdoc has them. These model objects aren't a mess like those under `robot.running`...
Because we don't have any model objects that could directly be used for this purpose, it could be that the best solution is adding a new entry point to `robot.api`....
One thing to take into account with the possible new API is how to handle argument conversion. As [this example](https://github.com/robotframework/robotframework/issues/4109#issuecomment-1059257115) demonstrates, `BuiltIn.run_keyword` handles conversion automatically. If we add an API...
I don't think continue-on-failure functionality is that important with Python code. You can simply avoid raising exceptions, and catch exceptions caused by code you call, until the keyword ends. For...
We decided to post-pone this to RF 3.1. Main reasons are: - We are running out of time with RF 3.0. - It is safer to deprecate changes first. That...
@fkberthold: Thanks for showing a use case where this functionality is used. It makes it explicit that this stuff is used also outside RF standard libraries and it cannot be...