Following our discussion from this years' March: The main problem here is get method which in general can return any type (more precisely in case of fmf: atomic types like float, int, str, maybe datetime, and None and compound types list and dict over them and over themselves). In languages like C/C++ get method return type will be some kind of union wrapped inside a struct but in Python we are using Any.
One solution to get rid off Any can be the API change: Instead of get, provide get_field_a, get_field_b, etc. to provide access to particular fmf fields; such methods can be annotated much more easily. Furthermore, as fmf format is described using JSON schema, we can use the schema to generate these methods together with their annotations instead of doing boring manual work but this step requires additional tooling. I am also aware that this means a lot of changes in the existing tmt codebase and other tools which are using fmf.
Following our discussion from this years' March: The main problem here is
getmethod which in general can return any type (more precisely in case offmf: atomic types likefloat,int,str, maybedatetime, andNoneand compound typeslistanddictover them and over themselves). In languages like C/C++getmethod return type will be some kind of union wrapped inside a struct but in Python we are usingAny.One solution to get rid off
Anycan be the API change: Instead ofget, provideget_field_a,get_field_b, etc. to provide access to particularfmffields; such methods can be annotated much more easily. Furthermore, asfmfformat is described using JSON schema, we can use the schema to generate these methods together with their annotations instead of doing boring manual work but this step requires additional tooling. I am also aware that this means a lot of changes in the existingtmtcodebase and other tools which are usingfmf.