The example in the description would be equivalent to this example using Python 3 function annotations:

def example(arg1: int, arg2, arg3: bool):
    # ...

One design decision to be made is how to handle specified types that don't match types we support. Here are some possibilities:

1. Make all unrecognized values always an error.
2. Make values that are not types an error. For example, int and str would be fine but 2 and 'foo' would cause an error.
3. Ignore non-type values altogether. Only use types we recognize for conversion. Show all types in Libdoc outputs.
4. Store all values and show them in Libdoc outputs. Only use values we recognize for conversion.

This is related to handling function annotations (#2890) that we don't recognize as supported types. Initially that design worked so that all annotations were shown in Libdoc outputs but only types we recognized were used for conversion (same as 4. above). That was later changed to throw all non-type annotations away, use values we recognize for conversion, and show all type annotation in Libdoc outputs (same as 3.). Because function annotations can be used also for other purposes than specifying types (see PEP-3107), we cannot make unrecognized annotations an error. With explicit types specified via the @keyword decorator that could be done, but I'm not sure is that a good idea.

I'm currently thinking we should preserve all types (and annotations) and show them in Libdoc outputs, but naturally only use types we recognize for conversion. This would allow using type information (and annotations) for documentation purposes as illustrated by PEP-3107 and would also be forward compatible with possible new types we support in the future. The only drawback I see is that someone could specify an incorrect type and it wouldn't be reported. I don't think that's very likely and the problem ought to be easy to see if any tests are created for the keyword.

Decided to implement this so that all given type information is preserved and shown by Libdoc. Obviously only types we recognize can be used for conversion.

Also decided to support giving arguments using a list like

@keyword(types=[int, bool])
def example(arg1, arg2):
    # ...

In simple cases this is less verbose than using a dictionary like

@keyword(types={'arg1': int, 'arg2': bool})
def example(arg1, arg2):
    # ...

Using a list with more arguments than there are types will cause an error, but having less types is fine and None as a type means no type. For example, this is equivalent to the example in the original description:

@keyword(types=[int, None, bool])
def example(arg1, arg2, arg3):
    # ...

Changed functionality so that using @keyword(types=None) disables argument conversion altogether, including getting type information based on default values.