Now that DIRAC is Python 3 only we can think about making use of Python's typing fuctionality. This was added in Python 3.5 however over the past few years it has grown to be really powerful and is even capable of understanding DIRAC's S_OK/S_ERROR convention (#6309).
A few ideas:
To expand on the last point, we could have a function like:
def export_something(dict[int, int]) -> dict[int, str]:
Currently the keys would become str due to the use of JSON however if the RPC call took advanage of the type hints we could easily cast to the correct type and remove the need to do type validate in every handler method. pydantic would likely be the best way to implement this, similarly to how fastapi works.
Now that DIRAC is Python 3 only we can think about making use of Python's typing fuctionality. This was added in Python 3.5 however over the past few years it has grown to be really powerful and is even capable of understanding DIRAC's
S_OK/S_ERRORconvention (#6309).A few ideas:
mypy(waiting for a release with generic TypedDict support Mypy 0.980 Release Planning python/mypy#13385)ReturnValues.pyis correctly typed (based on the example in [v8.0] Annotate ReturnValues.py #6309)diraccfg. Ideally this should include dropping Python 2 support.gConfigMonkeyTypeorpyannotateto add more type hints (maybe wait until we have a little more experience rather than adding wrong hints)typeguardorbeartypeto validate type hints at runtime when running testsTo expand on the last point, we could have a function like:
Currently the keys would become
strdue to the use of JSON however if the RPC call took advanage of the type hints we could easily cast to the correct type and remove the need to do type validate in every handler method.pydanticwould likely be the best way to implement this, similarly to howfastapiworks.