Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making use of Python typing #6315

Open
1 of 8 tasks
chrisburr opened this issue Aug 15, 2022 · 3 comments
Open
1 of 8 tasks

Making use of Python typing #6315

chrisburr opened this issue Aug 15, 2022 · 3 comments

Comments

@chrisburr
Copy link
Member

chrisburr commented Aug 15, 2022

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:

  • Add CI to run mypy (waiting for a release with generic TypedDict support Mypy 0.980 Release Planning python/mypy#13385)
  • Add tests to ensure that ReturnValues.py is correctly typed (based on the example in [v8.0] Annotate ReturnValues.py #6309)
  • Add type annotations to diraccfg. Ideally this should include dropping Python 2 support.
  • Add type annotations to gConfig
  • Fully type the contents of the CS so it's possible to statically validate (maybe impractical)
  • Allow RPC calls to be more richly typed for HTTPS
  • Try using MonkeyType or pyannotate to add more type hints (maybe wait until we have a little more experience rather than adding wrong hints)
  • Consider using typeguard or beartype to validate type hints at runtime when running tests

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.

@fstagni
Copy link
Contributor

fstagni commented Aug 17, 2022

If we do down this way, should we consider running https://github.com/Instagram/MonkeyType or https://github.com/dropbox/pyannotate?

@chrisburr
Copy link
Member Author

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 #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.

@fstagni
Copy link
Contributor

fstagni commented Oct 26, 2023

I'd move this to diracx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants