Open chrisburr opened 2 years ago
If we do down this way, should we consider running https://github.com/Instagram/MonkeyType or https://github.com/dropbox/pyannotate?
I hadn't considered that would even be a possibility. For bits with non-trivial DIRAC semantics (S_OK
/S_ERROR
/CFG
/executeRPC
/dict
) we'll need hand crafted types (like https://github.com/DIRACGrid/DIRAC/pull/6309) but for the long tail of "easy" cases that looks like a good idea. Once mypy
is updated (eta late August) and we have CI for it I'll take a look.
There is also the option of running tests with runtime type checking via tools like typeguard
or beartype
which might be interesting.
I'd move this to diracx
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:
mypy
(waiting for a release with generic TypedDict support https://github.com/python/mypy/issues/13385)ReturnValues.py
is correctly typed (based on the example in #6309)diraccfg
. Ideally this should include dropping Python 2 support.gConfig
MonkeyType
orpyannotate
to add more type hints (maybe wait until we have a little more experience rather than adding wrong hints)typeguard
orbeartype
to validate type hints at runtime when running testsTo expand on the last point, we could have a function like:
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 howfastapi
works.