Tutorial
7. Make the checker stricter
Some results have no proof. The checker knows the name of a column but not its data type, or it cannot know the columns of a frame at all. One setting decides which of these results are errors.
A result without a proof
Section titled “A result without a proof”map_elements runs a Python function on each value. The checker cannot read the function, so it cannot know the data type of the result:
Revealed type
TypedDataFrame[TypedDict({'symbol': String, 'price': Unchecked, 'quantity': Int64}, closed=True), None]The column price keeps its name, with the data type Unchecked. Every other check still applies: the other columns keep their data types, and a later step that reads price passes.
Make it an error
Section titled “Make it an error”The setting allow_unproven sets a level. A stricter level reports more of these results. At the level stated, the same line is an error:
[tool.astrolabe]allow_unproven = "stated"The note names two ways to let the line pass: a less strict level, or an override for one operation.
Give the checker the proof
Section titled “Give the checker the proof”Here, the better fix is to state the data type. return_dtype= names it, and the column is typed again:
Revealed type
TypedDataFrame[TypedDict({'symbol': String, 'price': Int64, 'quantity': Int64}, closed=True), None]The default level is omitted. A new project can start at a stricter level, and an existing codebase can start at the default. See Configuration for each level, and Adopting in an existing codebase.
This is the end of the tutorial. The Guides explain each topic in more detail.