Validation error with dummy filereport and expression referencing type_as_text #176
Comments
Merged
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 17, 2022
Our logic operators 'and' and 'or' would not short-circuit if the result was already conclusive. This would lead to unnecessary evaluation and broke user assumption that we they could be used to run additional tests only if required. We fix that by introducing short-circuiting and adding tests to document the problem and catch regressions. This now also allows tests to avoid error conditions like: foo is not None and "bar" in foo (NoneType not iterable in this case). Partially addresses scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 17, 2022
Python makes a distinction between something being contained in something else (or not) and something not being able to be contained in nothing (i.e. None) and raises a 'NoneType not iterable' exception in the latter case. We can see no application of this distinction in our use-case as of now. In fact it causes problems when writing tests against object properties which are None. Therefore we handle that case in our containment tests and interpret it as something (obviously) not being contained in nothing. Closes scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 18, 2022
Our logic operators 'and' and 'or' would not short-circuit if the result was already conclusive. This would lead to unnecessary evaluation and broke user assumption that they could be used to run additional tests only if required. We fix that by introducing short-circuiting and adding tests to document the problem and catch regressions. This now also allows tests to avoid error conditions like: foo is not None and "bar" in foo (NoneType not iterable in this case). Partially addresses scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 18, 2022
Python makes a distinction between something being contained in something else (or not) and something not being able to be contained in nothing (i.e. None) and raises a 'NoneType not iterable' exception in the latter case. We can see no application of this distinction in our use-case as of now. In fact it causes problems when writing tests against object properties which are None. Therefore we handle that case in our containment tests and interpret it as something (obviously) not being contained in nothing. Closes scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 18, 2022
Our logic operators 'and' and 'or' would not short-circuit if the result was already conclusive. This would lead to unnecessary evaluation and broke user assumption that they could be used to run additional tests only if required. We fix that by introducing explicit short-circuiting and adding tests to document the problem and catch regressions. We also fix over-eager short-circuiting for compound 'or' operations by excluding both 'or' and 'and' from post-evaluation short-circuiting and deferring their short-circuiting to the next iteration based on the then-first operand. Finally, we explicitly document the distinction between operand passing within compound operations (such as 1 < 2 < 2) and their evaluation into boolean results. We opt (as we did implictly before) to always return booleans even for 'and' and 'or' which in python return the determing operand (1 or 2 -> 1 instead of True). In order to determine what operation we're looking at, we switch 'and' and 'or' from lambda functions to static methods. This now also allows tests to avoid error conditions like: foo is not None and "bar" in foo (NoneType not iterable in this case). Partially addresses scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 18, 2022
Python makes a distinction between something being contained in something else (or not) and something not being able to be contained in nothing (i.e. None) and raises a 'NoneType not iterable' exception in the latter case. We can see no application of this distinction in our use-case as of now. In fact it causes problems when writing tests against object properties which are None. Therefore we handle that case in our containment tests and interpret it as something (obviously) not being contained in nothing. Closes scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 18, 2022
Our logic operators 'and' and 'or' would not short-circuit if the result was already conclusive. This would lead to unnecessary evaluation and broke user assumption that they could be used to run additional tests only if required. We fix that by introducing explicit short-circuiting and adding tests to document the problem and catch regressions. We also fix over-eager short-circuiting for compound 'or' operations by excluding both 'or' and 'and' from post-evaluation short-circuiting and deferring their short-circuiting to the next iteration based on the then-first operand. Finally, we explicitly document the distinction between operand passing within compound operations (such as 1 < 2 < 2) and their evaluation into boolean results. We opt (as we did implictly before) to always return booleans even for 'and' and 'or' which in python return the determing operand (1 or 2 -> 1 instead of True). In order to determine what operation we're looking at, we switch 'and' and 'or' from lambda functions to static methods. This now also allows tests to avoid error conditions like: foo is not None and "bar" in foo (NoneType not iterable in this case). Partially addresses scVENUS#176.
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
Mar 18, 2022
Python makes a distinction between something being contained in something else (or not) and something not being able to be contained in nothing (i.e. None) and raises a 'NoneType not iterable' exception in the latter case. We can see no application of this distinction in our use-case as of now. In fact it causes problems when writing tests against object properties which are None. Therefore we handle that case in our containment tests and interpret it as something (obviously) not being contained in nothing. Closes scVENUS#176.
michaelweiser
added a commit
that referenced
this issue
Mar 21, 2022
Our logic operators 'and' and 'or' would not short-circuit if the result was already conclusive. This would lead to unnecessary evaluation and broke user assumption that they could be used to run additional tests only if required. We fix that by introducing explicit short-circuiting and adding tests to document the problem and catch regressions. We also fix over-eager short-circuiting for compound 'or' operations by excluding both 'or' and 'and' from post-evaluation short-circuiting and deferring their short-circuiting to the next iteration based on the then-first operand. Finally, we explicitly document the distinction between operand passing within compound operations (such as 1 < 2 < 2) and their evaluation into boolean results. We opt (as we did implictly before) to always return booleans even for 'and' and 'or' which in python return the determing operand (1 or 2 -> 1 instead of True). In order to determine what operation we're looking at, we switch 'and' and 'or' from lambda functions to static methods. This now also allows tests to avoid error conditions like: foo is not None and "bar" in foo (NoneType not iterable in this case). Partially addresses #176.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Similar to #156, startup of Peekaboo fails with certain operators such as
inbecause the dummy filereport's properties return None. Example expression:Error message:
I guess, eiither our dummies need to get more realistic or we need to scale back the level of evaluation we're doing against them.
The text was updated successfully, but these errors were encountered: