Types for literals like this will be inferred by the type checker, so you can remove this

Agreed, but the mypy settings are quite aggressive so this errors if left off.

Then I think we should mark them as Final[float] etc. so that we're actually adding information here.

Suggest using @overload here to make the return type more specific.

@overload
def applyUnits(value: tuple[float, str]) -> str: ... 
@overload
def applyUnits(value: float) -> float: ...
def applyUnits(value):
 Implementation 

See https://typing.python.org/en/latest/spec/overload.html

Two small things here, first you don't need the type hints for the implementation version, and second you need a third overload for the str -> str case ☺️

It's not discouraged, and is arguably good practice, to have type hints on the implementation. It's just required that they are general enough to cover all possible options, where the overloads are intended to denote more specific scenarios to help constrain types.

That documentation you linked to shows this in most of the examples provided.

Hmm, the only spot in the docs that mentions the implementation is this section, which does imply that type hints on the implementation will be checked for consistency with the overloads. I won't object if they stay.

That said, none of the examples on the page show the implementation including type hints in the signature, except the counter-example in the consistency section. The only section that shows an "implementation" does not include the type hints (the def utf8 example) All the other examples implement a separate function test which is type hinted to show the overload rules, so they aren't relevant.

You're right, my mistake! I mistook the last overload shown to be the implementation in the examples which did not show an implementation at all.

The base thermo class also requires a definition of model, as it's accessed within the get_yaml function below. I believe on the base class this would only requires a type and not a value, so it could be model: ClassVar[str] here.

Setting the value of model here is fine, and probably preferable, but if you do it this way you need to also remove the assignment in __init__, on line 474. Attempting to assign to a variable marked as Final is a type error. Most of the remaining errors are of this type, and your Python LSP should be putting red underlines on these within your IDE.

I'm seeing an error that says Cannot override writable attribute "pref" with a final one. This is because the base class defines pref as an assignable value of type float | None. I see what you're trying to do here, but I haven't used Final enough to suggest the right way to type this.

I suspect this line should just be pref = None, as the type is already set by the base class and I'm not sure a subclass can force it to be more narrow and/or Final.

You don't need to redefine pref and its type, as it's inherited from the base class.

This is flagged as an error: unused-ignore within the mypy check, but I can see how it might be required for the stubtest checks. I'm not sure what to do about that, exactly, but we might need to change unused-ignore to a warning instead of an error. That should be an option that can be set in the pyproject.toml file.

Final is propagated through to subclasses, so because surface_reaction has type: Final = "surface", you can't change it here. Consider using ClassVar[str] instead of Final.

It even says as much in the tooltip when I hover over Final:
image