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
With the typeguard jobs kicked off, the vast majority of our tests fail. This is due to slight type mismatches due to the Pyparsing library having their own types.
I think that the thing that's going to cause the most problems however is going to be the actual Parse method itself as it is now a ParseResults object, which is a List[Any], but in actuality is List[string, int, float, EvaluationResults], e.g. [1, "+", 2.5].
This is going to be a headache and a half to deal with and I am really worried because I have done stuff like check types ahead of time and raise exceptions if types are not what we expect (however, they should always be what we expect and it's impossible to my knowledge to test without mocking the function and having bad returned values). We may be able to get away with a one-liner so that we can still hit 100% code coverage with something like: if not isinstance(var, (type, type)): raise Exception, but I would like to stay away from that sort of thing if possible because I do not know if Black will like it and it's a pretty hacky workaround.
Another way we can insure types is by having a helper static method in our parser that takes input and ensures it's what we're expecting. That would be testable to cause it to throw, allowing us our 100%.
The text was updated successfully, but these errors were encountered:
With the typeguard jobs kicked off, the vast majority of our tests fail. This is due to slight type mismatches due to the Pyparsing library having their own types.
I think that the thing that's going to cause the most problems however is going to be the actual Parse method itself as it is now a ParseResults object, which is a List[Any], but in actuality is List[string, int, float, EvaluationResults], e.g.
[1, "+", 2.5]
.This is going to be a headache and a half to deal with and I am really worried because I have done stuff like check types ahead of time and raise exceptions if types are not what we expect (however, they should always be what we expect and it's impossible to my knowledge to test without mocking the function and having bad returned values). We may be able to get away with a one-liner so that we can still hit 100% code coverage with something like:
if not isinstance(var, (type, type)): raise Exception
, but I would like to stay away from that sort of thing if possible because I do not know if Black will like it and it's a pretty hacky workaround.Another way we can insure types is by having a helper static method in our parser that takes input and ensures it's what we're expecting. That would be testable to cause it to throw, allowing us our 100%.
The text was updated successfully, but these errors were encountered: