This was originally reported as part of #5622. As discussed in that issue, the reason is that in Python bool is a sub type of int (i.e. isinstance(True, int) is true) and Robot argument conversion in general allows sub types to be used. This Python design is quite widely considered a mistake and it certainly is confusing in Robot's context. Changing the argument conversion behavior could thus make sense.
A problem with changing the behavior is that changes like this are backwards incompatible. It can be argued, and I would agree, that if you have a keyword like
def example(arg: int):
...it's very unlikely that you would expect the argument to be a Boolean. If what would be the case, changing the implementation to more explicit
def example(arg: int | bool):
...would preserve the current functionality.
The change would also affect the case where argument conversion is done based on the default value type like
In this case preserving the current behavior would require adding type hints, which may be a bigger ask than updating current type hints. It is, however, somewhat unlikely that there are lot of cases where argument conversion is done based on an integer type hint and the value would be passed in as a Boolean.
Overall I consider backwards incompatibility issues so small with this particular change, that I don't see big problems doing it in a feature released (i.e. RF 7.5) instead of waiting for a major version (i.e. RF 8.0) where backwards incompatible changes in general are tolerated more. That said, I don't think Boolean values are that often passed to functions expecting integer values and I doubt that such usage even causes problems too often. Thus waiting for RF 8.0 to get this small issue fixed shouldn't be a big problem either.
This was originally reported as part of #5622. As discussed in that issue, the reason is that in Python
boolis a sub type ofint(i.e.isinstance(True, int)is true) and Robot argument conversion in general allows sub types to be used. This Python design is quite widely considered a mistake and it certainly is confusing in Robot's context. Changing the argument conversion behavior could thus make sense.A problem with changing the behavior is that changes like this are backwards incompatible. It can be argued, and I would agree, that if you have a keyword like
it's very unlikely that you would expect the argument to be a Boolean. If what would be the case, changing the implementation to more explicit
would preserve the current functionality.
The change would also affect the case where argument conversion is done based on the default value type like
In this case preserving the current behavior would require adding type hints, which may be a bigger ask than updating current type hints. It is, however, somewhat unlikely that there are lot of cases where argument conversion is done based on an integer type hint and the value would be passed in as a Boolean.
Overall I consider backwards incompatibility issues so small with this particular change, that I don't see big problems doing it in a feature released (i.e. RF 7.5) instead of waiting for a major version (i.e. RF 8.0) where backwards incompatible changes in general are tolerated more. That said, I don't think Boolean values are that often passed to functions expecting integer values and I doubt that such usage even causes problems too often. Thus waiting for RF 8.0 to get this small issue fixed shouldn't be a big problem either.