Skip to content

Argument conversion and validation with non-string argument values #3735

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
pekkaklarck opened this issue Oct 22, 2020 · 2 comments
Closed

Argument conversion and validation with non-string argument values #3735

pekkaklarck opened this issue Oct 22, 2020 · 2 comments
Labels
alpha 2 backwards incompatible enhancement priority: high
Milestone
v4.0

Comments

@pekkaklarck
Copy link
Member

When argument conversion was added in RF 3.1 (#2890, #2947, #2932) a decision was made that conversion is done only if the given argument is a Unicode string. This approach has some limitations and a decision has been made to support conversion also with other argument types.

The problem here is that there is an unlimited amount of types users could use and handling all cases sanely is likely not easy. There are, however, many simple and useful cases like converting an integer to a float if a keyword accepts arg: float and accepting numbers with arg: timedelta.

One important decision to be made is handling types we cannot convert. For example, if we have arg: int and it is called with None, what should we do. We can either pass the given argument as-is or, probably better, make it an error. Making this an error is backwards incompatible change, though.
@pekkaklarck pekkaklarck added this to the v4.0 milestone Oct 22, 2020
@pekkaklarck pekkaklarck mentioned this issue Oct 22, 2020
Closed
pekkaklarck pushed a commit that referenced this issue Oct 22, 2020
@mkorpela
Add argument conversion when given argument is int or float
ce5adaf 
This also makes it easy to add conversion to other non-string arguments as discussed in #3735.
@pekkaklarck
Copy link
Member Author

pekkaklarck commented Oct 25, 2020 •
edited
Loading

Conversion logic will be changed like this:

  1. Following converters are enhanced to accept listed non-string values. Unless explicitly noted, value is converted to the expected type.

    • BooleanConverter: int, float and None are accepted and passed as-is without conversion.
    • IntegerConverter: float is accepted if no precision is lost (e.g. 1.0 is ok but 1.1 is not).
    • FloatConverter: int is accepted
    • DecimalConverter: int and float are accepted
    • DateTimeConverter: int and float are accepted and considered to be an epoch timestamp
    • TimeDeltaConverter: int and float are accepted and considered seconds
    • BytesConverter: bytearray is accepted
    • ByteArrayConverter: bytes is accepted
    • ListConverter: tuple is accepted
    • TupleConverter: list is accepted
    • SetConverter: frozenset, list, tuple and dict are accepted
    • FrozenSetConverter: set, list, tuple and dict are accepted

  2. All converters also accept values of their own type and pass them as-is.

  3. All other types are considered to be errors.

pekkaklarck added a commit that referenced this issue Oct 25, 2020
@pekkaklarck
Remove int -> bytes type conversion.
fbde89f 
Related to #3735.
pekkaklarck added a commit that referenced this issue Oct 25, 2020
@pekkaklarck
More non-string argument conversions (#3735)
75eebeb 
1. More conversions:

   - Boolean: int, float and None are accepted without conversion
   - Decimal: int and float are converted
   - Bytes/ByteArray: bytearray/bytes is converted
   - List/Tuple: tuple/list is converted
   - Set/FrozenSet: frozenset/set, list, tuple and dict are converted

2. Other argument types cause conversion error.
@pekkaklarck
Copy link
Member Author

This issue ought to be done except for updating the User Guide. That will be done soonish when all type conversion enhancements are done.

@pekkaklarck pekkaklarck changed the title Argument conversion should work also when given argument isn't a string Argument conversion and validation with non-string argument values Oct 25, 2020
@pekkaklarck pekkaklarck mentioned this issue Oct 25, 2020
Closed
mkorpela pushed a commit that referenced this issue Nov 2, 2020
@pekkaklarck @mkorpela
UG: Document argument conversion changes.
24cec81 
- Union support. Fixes #3738.
- Conversion with non-string values. Fixes #3735.
- Conversion to string. Fixes #3736.
- None as an alias for NoneType. Fixes #3739.
- Stricter None conversion. Fixes #3729.
vokiput pushed a commit to vokiput/robotframework that referenced this issue Dec 27, 2020
@mkorpela
Add argument conversion when given argument is int or float
14b2bbb 
This also makes it easy to add conversion to other non-string arguments as discussed in robotframework#3735.
vokiput pushed a commit to vokiput/robotframework that referenced this issue Dec 27, 2020
@pekkaklarck
Remove int -> bytes type conversion.
9bb2e34 
Related to robotframework#3735.
vokiput pushed a commit to vokiput/robotframework that referenced this issue Dec 27, 2020
@pekkaklarck
More non-string argument conversions (robotframework#3735)
a3acbc9 
1. More conversions:

   - Boolean: int, float and None are accepted without conversion
   - Decimal: int and float are converted
   - Bytes/ByteArray: bytearray/bytes is converted
   - List/Tuple: tuple/list is converted
   - Set/FrozenSet: frozenset/set, list, tuple and dict are converted

2. Other argument types cause conversion error.
vokiput pushed a commit to vokiput/robotframework that referenced this issue Dec 27, 2020
@pekkaklarck
UG: Document argument conversion changes.
90c037c 
- Union support. Fixes robotframework#3738.
- Conversion with non-string values. Fixes robotframework#3735.
- Conversion to string. Fixes robotframework#3736.
- None as an alias for NoneType. Fixes robotframework#3739.
- Stricter None conversion. Fixes robotframework#3729.
This was referenced Feb 22, 2021
Closed
Closed
@pekkaklarck pekkaklarck mentioned this issue Mar 26, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
alpha 2 backwards incompatible enhancement priority: high
Projects
None yet
Milestone
v4.0
Development

No branches or pull requests
1 participant
@pekkaklarck