You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
collections.abc.ByteString that Robot's argument conversion supports has been deprecated in Python 3.12 and will be removed in Python 3.14. This basically makes the current Robot Framework code incompatible with Python 3.14 that's released already in 2025, and also means that there are deprecation warnings with Python 3.12 already now.
ByteString conversion isn't that useful and I believe the best way to handle these problems is to simply not support it. This is how conversion currently works if you use arg: ByteString:
If the given argument is an instance bytes or bytearray (i.e. is already an instance of ByteString), it is passed to the keyword as-is.
Otherwise, it is converted to bytes the same way as if the keyword would have used arg: bytes.
I don't consider these semantics too useful. I don't see how often you'd like to have a keyword that gets either bytes or bytearray, when you could use arg: bytes or arg: bytearray to get one of them. More importantly, if you have such a need, using arg: bytes | bytearray works exactly the same way and makes then intention more clear.
Removing the support for ByteString conversion is obviously a backwards incompatible change, but I doubt there are many users for it, they can easily use bytes | bytearray instead, and they anyway need to do that relatively soon when ByteString will be gone. I wish we would have done this earlier in RF 7.0 development cycle, but believe doing it still now before the release candidate is fine.
The text was updated successfully, but these errors were encountered:
There actually aren't any deprecation warnings with Python 3.12 unless you actually use arg: ByteString yourself. We do import ByteString in Robot's type conversion code, but that alone isn't enough to trigger the deprecation warning. We only get it when using ByteString for something:
Users typically not seeing deprecation warnings with Python 3.12 makes removing ByteString support a little less urgent. The import we have will certainly fail with Python 3.14, though, and I believe we should remove it already now. We obviously could avoid the import only with Python 3.12 and newer or get ByteString from collections.abc dynamically with getattr, but because ByteString conversion isn't that useful I don't think anything like that is worth the effort.
collections.abc.ByteString that Robot's argument conversion supports has been deprecated in Python 3.12 and will be removed in Python 3.14. This basically makes the current Robot Framework code incompatible with Python 3.14 that's released already in 2025, and also means that there are deprecation warnings with Python 3.12 already now.
ByteString
conversion isn't that useful and I believe the best way to handle these problems is to simply not support it. This is how conversion currently works if you usearg: ByteString
:bytes
orbytearray
(i.e. is already an instance ofByteString
), it is passed to the keyword as-is.bytes
the same way as if the keyword would have usedarg: bytes
.I don't consider these semantics too useful. I don't see how often you'd like to have a keyword that gets either
bytes
orbytearray
, when you could usearg: bytes
orarg: bytearray
to get one of them. More importantly, if you have such a need, usingarg: bytes | bytearray
works exactly the same way and makes then intention more clear.Removing the support for
ByteString
conversion is obviously a backwards incompatible change, but I doubt there are many users for it, they can easily usebytes | bytearray
instead, and they anyway need to do that relatively soon whenByteString
will be gone. I wish we would have done this earlier in RF 7.0 development cycle, but believe doing it still now before the release candidate is fine.The text was updated successfully, but these errors were encountered: