Thank you for your response! :)
I was thinking to start with adding type hints to some basic Django packages, i.e. django.utils, and then move on with other ones, depending on how much time I have left.
But, I'm not sure what way to do this is more reasonable. I wrote an email to Daniel Moisset (@dmoisset at Github) who used to work on adding type hints to Django. He suggested to use Mypy stubgen in order to provide
.pyi files and distribute them as PEP 561 package (as part of the django package, or an officially supported package). In fact, there is a big existing project od adding stubs to Django (
https://github.com/typeddjango/django-stubs), and it's being discussed as DEP 65.
This seems to be quite nice solution, but a few months ago Carlton Gibson described it as "work around" (https://github.com/django/deps/pull/65#issuecomment-539505849) so I hope he will read this email and give me some feedback on this one. As long as contributing to
https://github.com/typeddjango could be considered as contributing to Django itself, I could reach Maksim Kurnikov (@mkurnikov at Github) to ask what needs to be done and include it in my proposal.
So, the other option is to add type hints by integrating the annotations in the upstream codebase. That would make it easier to maintain, and can have some benefits from the documentation standpoint. Then adding some integration of type checking to Django's CI; this would ensure annotations are kept up to date. I would love to try doing this as my GSoC contribution, but before I send you my proposal I want to know what you guys think about this.
Ofcourse I'm aware that adding type hints to such big project as Django is not a "side project for the weekends", but according to GSoC rules it's not crucial to get one's commits merged to the project by the end of program. As a student who's doing well at Uni I'm willing to spend much of my free time on adding type hints to Django.
Kindest regards,
Kacper