Improve boolean handling
aaltat opened this issue · comments
In library there is this code:
def set_ignore_implicit_angular_wait(self, ignore):
if not is_boolean(ignore):
raise TypeError("Ignore must be
But it might be better to use Robot Framework or SeleniumLibrary is_truthy method to improve boolean handling. SeleniumLibrary method is in here: https://github.com/robotframework/SeleniumLibrary/blob/master/src/SeleniumLibrary/utils/types.py
And it has been there since 3.0 release.
SeleniumLibrary boolean handling is explained in here: http://robotframework.org/SeleniumLibrary/SeleniumLibrary.html#Boolean%20arguments
I can provide you a pull request to fix the problem. Should I copy paste the implementation or can I use method from the SeleniumLibrary? If I can, it will raise minimum required SeleniumLibrary to 3.0.
[Note this is a general comment for the community and not one directed just at Tatu as this is really a community agreed upon standard]
I am hesitant to make this change as I am not sure I agree with the values one can use for true. I am fine with any Python Boolean equivalent ${True} and trying to think through the consequences of other evaluations of Python True, like an non zero integer. [There might be a bug in the current code such that a non zero integer, although True in Python, is still of type 'int' and would cause an uncaptured type error.] But I don't really like the use of plain test strings as boolean values. Now I do agree that Robot Framework is a natural language test framework so it makes a lot of sense to be able to then use natural language when scripting. But my problem lies in where does one start and stop with the natural language version of ${True}/${False}? Ok I would start with true, as a string, but if one continues onto yes where does one stop. I see off is considered ${False} so would we allow on as ${True}. Going to the thesaurus it lists 33 synonyms for yes with the top seven being affirmative, amen, fine, good, okay, true, yea. There is forty seven synonyms for true. And those are just the English terms which internationalization really really really matters to me and I want to be able to support. [It plays an important part of how I first got introduced to Robot Framework].
So it is easier for me to say let's stick to boolean types (which again there may be a bug here so disregarding that for the moment ..). Now it may make sense for compatibility to simply accept the relationship of the SeleniumLibrary forces me to use what it calls as true. But as stated I am hesitant to make this change and at this time dragging my feet on this one ...
As long as the documentation is clear, a solution considering a small set of truthy values would be OK. I believe that was the choice done in Robot Framework. In the case of AngularLibrary, when we Import the library we can pass the option ignore_implicit_angular_wait=False (on the example we have ignore_implicit_angular_wait=${true}), but then the same was not valid for Set Ignore Implicit Angular Wait which works with ${True}.
The inconsistency between the Library Import and keyword is problematic.
The documentation has been updated to note the argument requirements of a Boolean type for the keyword. In addition a note was added about the discrepancy between the arguments for the library import and the ignore implicit angular wait.
As I am still on the fence about adding this restrictions as outlined and used in SeleniumLibrary I will leave this ticket open for a while..
Actually original usage case comes from the Robot Framework core, where this was originally introduced. Generally if feel, that in the test data it's easier to read:
| Keyword | False |
Than use this:
| Keyword | ${False} |
And treat both of them as Python False in the library side.