To make the construction of bespoke cosmology classes easier, we could provide a set of standard type definitions.
For example, going by our current definitions:
ScalarOrArray, which accepts a single scalar or an arrayArray, which is always an array (since I believe we agreed on returning 0D arrays?) — this exists but isn't part of the standard.
Then it could be idiomatic for library maintainers to define generic cosmology interfaces like this:
ConstantT = TypeVar("ConstantT", bound=cosmology.api.ScalarOrArray)
RedshiftT = TypeVar("RedshiftT", bound=cosmology.api.ScalarOrArray)
ResultT = TypeVar("ResultT", bound=cosmology.api.Array)
class Cosmology(
cosmology.api.HasC[ConstantT],
cosmology.api.HasX0[ResultT],
cosmology.api.HasY[ResultT, RedshiftT],
Protocol,
): ...
def f(z: RedshiftT, cosmo: Cosmology[ResultT, RedshiftT]) -> ...:
...In the future, we could then introduce refined types for constants, redshifts, wavenumbers, etc. if we ever found them to behave slightly differently.
Besides, we should document that the type args of our protocols are always ordered in the same way: HasX[ResultT, ArgT1, ArgT2], with result first, then first type for arguments, second, etc.
To make the construction of bespoke cosmology classes easier, we could provide a set of standard type definitions.
For example, going by our current definitions:
ScalarOrArray, which accepts a single scalar or an arrayArray, which is always an array (since I believe we agreed on returning 0D arrays?) — this exists but isn't part of the standard.Then it could be idiomatic for library maintainers to define generic cosmology interfaces like this:
In the future, we could then introduce refined types for constants, redshifts, wavenumbers, etc. if we ever found them to behave slightly differently.
Besides, we should document that the type args of our protocols are always ordered in the same way:
HasX[ResultT, ArgT1, ArgT2], with result first, then first type for arguments, second, etc.