Unexpected parsing behaviour for --date=2018-12-09 vs. --date=2018-12-10

[martinvirtel]

Anything that can be interpreted as an arithmetics expression will be magically "calculated" by fire. This is very practical. But it bit me because I wanted to parse dates from command line parameters using fire, see below.

Suggestion: accept type hints as a way to prevent this. A parameter with type hint "str" shoud not be "calculated".

Test code:

def test(string: str=None) :
    print(string)

if __name__=="__main__" :
    fire.Fire(test)

Will give you:

> python ./test-parsing.py --string=2010-10-10
1990    # not interpreted as a string, but as 2010 minus 10 minus 10

> python ./test-parsing.py --string=2010-10-09
2010-10-09

[dbieber]

Definitely agree that this is an issue.
In my view, it's also an issue even when there is no type annotation.
Expressions like 2010-10-10 should not be evaluated by Fire; only literals and collections of literals should be parsed by default. (Issue #97)

[danishprakash]

I would like to fix this @dbieber if nobody else is and while we're at it, do you already have an approach in mind for tackling this?

[dbieber]

Yes, see my comment here: #97 (comment)

[dbieber]

I think this was fixed at least by 0.2.1, though maybe it was earlier.