Hi @Alex,
I wasn't aware of the fellowship program, but I've been getting started to work at this and I already have some minimal things up I have a repo with type hints (currently just covering the HttpRequest object and other minor stuff) at https://github.com/machinalis/mypy-django ; I'm currently working on the HttpResponse object (with that I can already have some typehinting at my views). To work on it I'm actually doing annotations on the source code (I have a forked django at https://github.com/dmoisset/django/tree/typing-requests ), and then converting those to stub files, In that way I can run the checker against the actual code and ensure the annotations are consistent. I was planning to make a comment about these here when they were a bit more mature with some minimal example, but given that the discussion already got here I think they may help. @Markus If there's interest in the community, I volunteer for the process of getting in charge of the discussion and drafting of the DEP. I wanted to know first how the community feels about these. @Florian Would you care to ellaborate? I couldn't find the post you mention (although requests is one of the few 3rd party projects that have support at the official typeshed repository, https://github.com/python/typeshed ) * @all For those of you wondering what all these is about, it's about adding static type hints to the arguments/result types of the results in Django. Currently there are 2 ways to do this: A) As a 3rd party project, providing separate "interface files" that mimic the ones with django, only with the function/method signatures B) As inline annotation in the django code (think of it as structured docstrings) Option (A) has the benefit of not interfering at all with the project, with the burden that it's harder to maintain and keep in sync when django makes new releases; it only helps django users Option (B) is easy to keep in sync and can help with django development itself, but it may imply some process changes (integrating a checker into CI, and in some very specific cases making contributors aware of it). Another drawback is that given that django still supports python 2, we need to use the "#type" comments instead of python3 annotations that are quite uglier. I've been working doing this for some internal projects at Machinalis and for a couple open source projects. So let me add a few comments that I already know that are frequently asked questions: * This has minimal to zero impact on runtime (probably adding a few imports). It's comparable to adding docstrings to a module that doesn't have it. The annotation is for outside analyzer tools (checkers and linters) running on CI, not on the django project itself * This does not have to be done project-wide, so it's not a huge undertaking; the point of gradual typing is that you can work at function granularity and build up. That's why I've started in small but visible modules like HttpRequest/HttpResponse. * In fact, there are some parts of django that will probably not be covered for a long time (I thinking QuerySets here) because they would need substantial support from the tool to make sense * The main goal of this is NOT detecting bugs (tests generally work ok). The goal is providing accurate documentation about function inputs and outputs that can help humans (for example people asking themselves "are the keys of request.FILES bytes or unicode?"), and tools (for example documentation generators that could expose this info, code editors that can add autocompletion, etc) * In a codebase with builtin annotations, it may help detecting simple bugs more quickly than the test suite; it works well integrated with an editor (in the same way that tools like pep8/flake8 detect simple things there). The power here increases as you get more core annotated (but again, it may work gradually). I also wanted to reinforce that I'm not asking somebody else to do it... I need this, so I'm already working on it, but I welcome anyone to join :) Best, D. On Wed, Aug 17, 2016 at 5:08 AM, Alexander Hill <a...@hill.net.au> wrote: > Hi all, > > I like the plan to include PEP 484 type hinting in Django, outlined in the > PyCharm promotion blog post. [1] > > Has this proposal been fleshed out much? Is there any extra information > available anywhere that I've missed? I think this will be great for Django, > and I'd happily contribute to the effort. > > Cheers, > Alex > > [1] https://www.djangoproject.com/weblog/2016/jun/30/ > pycharm-and-django-fundraiser/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/CA%2BKBOKzHPhsqeZGF4ebcc2eCuMjpSs > N4MfWFAMxzFXjU%3D2-isw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CA%2BKBOKzHPhsqeZGF4ebcc2eCuMjpSsN4MfWFAMxzFXjU%3D2-isw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Daniel F. Moisset - UK Country Manager www.machinalis.com Skype: @dmoisset -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALuYSZXpEcFKx2spQacL16eJfun06j4ou4VbSSnM2zQ9zswEkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
