autowisp.browser_interface.diagnostics.expression_data module

Class Inheritance Diagram

Where the expression library comes from, when it comes from the BUI.

Tier 3 of the expression layer, and the only place outside the views that knows Django. Tiers 1 and 2 take the library as an argument – a plain {name: expression} dictionary – precisely so that they need not know whether it was stored by the browser interface, read out of an exported file by run_pipeline, or written down in a test. This module is the first of those sources.

It is deliberately thin. Everything one might be tempted to put here – what an expression means, which order to evaluate a library in, what is wrong with a proposed one – belongs to autowisp.diagnostics.expressions, where it can be tested without a database of either kind, and is reached from here only by callers that already have both.

autowisp.browser_interface.diagnostics.expression_data.get_expression_descriptions()

Return {name: description} for the stored expressions.

Kept apart from get_expressions(), which everything that evaluates an expression consumes: what a quantity is for is of no interest to the evaluator, and a dictionary carrying both would have to be taken apart again by every caller of it.

Returns:

Every stored expression’s description, the empty string

where one was left blank.

Return type:

dict

autowisp.browser_interface.diagnostics.expression_data.get_expressions()

Return the stored library as {name: expression}.

The whole library, not the part that is usable in the open project: an expression naming a diagnostic this project never recorded is not an error but a thing to leave unoffered. Every expression is valid everywhere – the vocabulary is the same in all projects, see autowisp.diagnostics.diagnostic_types – so what varies is only whether rows exist, which callers that care establish by counting them.

Returns:

Every stored expression, keyed by name.

Return type:

dict