Typesheds will be a pain to maintain across versions. Based on my
experience with typescript typings, the most immaculate situation is
shipping typings within the project, even though shipping external typings
is mature in that case. Nevertheless, inline typings can help Django
project development as well.
Adding to the docs any future plans regarding this, would be helpful for
prospective developers.
--
Ticket URL: <https://code.djangoproject.com/ticket/29299>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> Adhering to [https://www.python.org/dev/peps/pep-0484/ Type hints(PEP
> 484)] / [https://www.python.org/dev/peps/pep-0526/ type annotations]
> could contribute to being more explicit / performing code analysis and
> checks on Django projects. Intellisense based on type annotations can
> also contribute to faster and less error-prone coding experience.
>
> Typesheds will be a pain to maintain across versions. Based on my
> experience with typescript typings, the most immaculate situation is
> shipping typings within the project, even though shipping external
> typings is mature in that case. Nevertheless, inline typings can help
> Django project development as well.
>
> Adding to the docs any future plans regarding this, would be helpful for
> prospective developers.
New description:
Adhering to [https://www.python.org/dev/peps/pep-0484/ Type hints(PEP
484)] / [https://www.python.org/dev/peps/pep-0526/ type annotations] could
contribute to being more explicit / performing code analysis and checks on
Django projects. Intellisense based on type annotations can also
contribute to faster and less error-prone coding experience.
Typesheds will be a pain to maintain across versions. Based on my
experience with typescript typings, the most immaculate situation is
shipping typings within the project, even though shipping external typings
is mature in that case. Nevertheless, inline typings can help Django
project development as well.
Adding to the docs any future plans regarding this would be helpful to
prospective developers.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:1>
* component: Uncategorized => Core (Other)
* stage: Unreviewed => Someday/Maybe
Comment:
This is [https://groups.google.com/d/topic/django-
developers/trTEbURFhEY/discussion discussed on django-developers] but a
consensus on how to proceed hasn't emerged.
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:2>
* cc: Adam (Chainz) Johnson (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:3>
* cc: Zach Borboa (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:4>
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:5>
* cc: Vlastimil Zíma (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:6>
Comment (by Brylie Christopher Oxley):
I am available to help with this issue. Is there a checklist of files or
areas, so that I can take a few to start?
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:7>
Comment (by Tim Graham):
See comment 2 and post on the mailing list if you want to try to get a
consensus on a way forward.
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:8>
Comment (by Sergey Kolomenkin):
Are there any updates on this ticket?
Does Django has some roadmap for adding type hints support to Django?
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:9>
Comment (by Tim Graham):
No updates. The discussion is on the mailing list linked in comment 2.
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:10>
Comment (by Yngve Høiseth):
Note the existence of [https://github.com/typeddjango/django-stubs django-
stubs].
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:11>
Comment (by Andreas Galazis):
Adding them in the framework would make changes to the framework more
smooth since typings would be updated within the codebase and there will
be no need for a new stub release (or waiting for the stub release).
I understand that it might involve a bit of donkey work to merge the stubs
in the framework.
If we find a tool to merge it automatically, would it be acceptable?
As a side note I stumbled on this:
https://pythonrepo.com/repo/ambv-retype-python-code-refactoring
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:12>
Comment (by Thiago Bellini Ribeiro):
Just to add here too, this project here is a fork of the original `django-
stubs` but without the mypy dependency and that works fine with pyright.
It has some interesting stuff in it, like defined a field with
`null=True`/`null=False` automatically types it as being able to get/set
None together with the field's primary type.
--
Ticket URL: <https://code.djangoproject.com/ticket/29299#comment:13>