So we in the technical board were a bit opaque and had our discussion in private before Carlton posted our summary. Apologies for this. We'll repeat the discussion in the open so you can see our reasoning.
On 4 March Carlton prompted for our input. I replied: My experience using types, so far: > > - I'm the author of flake8-no-types, the flake8 plugin for banning type > annotations 😂 I wrote it whilst reviewing a client's code base which had > type annotations, mostly added by PyCharm autocomplete, but no MyPy > running. Running MyPy produced >1k errors. Eventually I actually fixed the > errors rather than stripping the annotations and installing flake8-no- > types - there was thankfully a lot of repetition in the errors. > - I have a vague memory writing one open source PR using types but > can't remember the project. > - I'm a little confused keeping up with the various ways of declaring > types, 'best practices", and which type checkers are out there (last I > heard there are 4!?). > > I agree that the tools are young, and evolving relatively quickly - both > MyPy and the standard library. I'm not sure there's quite enough stability > yet to roll types out across the whole of Django. > > There's the risk that we end up in a chicken/egg stalemate where if no > major Python project commits to being typed, types don't get enough > adoption to progress. But I think there are enough popular projects, like > Starlette, that are using them. > > At current it does seem to be a vocal niche of developers who want them. > > > Yes it will make PR's harder to review, and definitely adds a barrier to > contribution. Even relatively Pythonic Django-ey constructs like "accept > anything with an as_expression method, or castable to a string" require > quite a lot of type system knowledge to write correctly. On top of this > the best practices seem to still be changing. > > > One extra benefit would be a little more clarity around Django API's. For > example, I think a past mistake was allowing database expressions' 'params' > to be *either* a tuple or list, which means casting everywhere (a bug for > years in django-mysql: > https://github.com/adamchainz/django-mysql/pull/558/files ). That said > this is relatively low impact - the documentation often doesn't mention > types at all and Python developers are used to checking things in a REPL. > > I think accepting the current PR is okay. [the one for __class_getitem__ ] > > A next step could potentially be experimentally by providing type > annotations in more limited scope projects. One that could work well is > asgiref, as it could also provide "the" ASGI type signatures - which > Starlette already started internally: > https://github.com/encode/starlette/blob/master/starlette/types.py > On Tue, 14 Apr 2020 at 10:46, Carlton Gibson <carlton.gib...@gmail.com> wrote: > Hi all. > > The question of using typing, or type hints, or type checking, in (or > with) Django > has come up several times. Whether we would add inline annotations, or use > stub > files, or what? > > Most recently, this resulted in a draft DEP[0] to try and formalize the > situation, > followed by a PR[1] adding the `__class_getitem__()` to `QuerySet` and > `Manager` > that would ease the job of working on external stub files. > > [0]: https://github.com/django/deps/pull/65 > [1]: https://github.com/django/django/pull/12405 > > There was extended discussion on both the draft DEP and the PR, which I > recommend for anyone particularly interested in this topic. > > Given the lack of consensus on the issue, I asked the Technical Board to > review > the situation in full, and make a judgement on the way forward. > > Having been charged to do so, I here post the Technical Board's response: > > > It is the view of the Django Technical Board that inline type > annotations > should not be added to Django at the current time. > > A brief idea of the considerations are these: > > * Typing in Python is still young and in flux. As such it is not > sufficiently stable. > * There are competing technologies, which may settle with time, but at > this > moment Django is not in a position to favor any one. > * Writing correct type hints is hard. And reviewing them to ensure > correctness isn't any easier. Even ostensibly simple examples often > have > hidden complexity. Thus the barrier to contribution and maintenance > is > raised. > * Due to the very dynamic nature of much of Django, example type hints > very > often do not pass an acceptable standard for readability. This might > be > manageable with extensive aliasing but that effort itself involves > further overhead. > > The Technical Board acknowledges the type checking is gaining ground in > Python and that many users are keen to employ it. > > The django-stubs project is notable for the impressive work that it has > done adding external stub files for Django. > > It is the view of the Technical Board that non-invasive changes in > order to > assist the work of external projects such as django-stubs are > acceptable. > > In particular, this means that the pull request to add the > `__class_getitem__()` method to QuerySet and Manager should be > accepted. > > A small number of further changes of a similar nature may be accepted, > but > the Technical Board wishes to emphasise that where possible typing > should > be done in external stub files, and that the barrier for further inline > changes will be high. > > We're looking forward to seeing how typing evolves in Python and > re-evaluating Django's position as things change. > > > On the basis of this, Mariusz and I (in our role as Mergers) shall review > and > merge the PR #12405 in time for Django 3.1. (We will also close the draft > DEP, > and any related tickets, over the coming period.) > > Personally, I wish to thank everybody who has participated in the > discussion to > bring us to this point. > > Kind Regards, > > Carlton > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/47283a09-7899-4449-8792-e31b5c779c4e%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/47283a09-7899-4449-8792-e31b5c779c4e%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Adam -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0-NYTrChBTzjHTak6HhH5Pbkrmo_UQ4yFqJ6i_WurcBA%40mail.gmail.com.
