Thanks for the replies, As I mentioned, I have already started implementation (and I'm willing to go through with it, having even some time from my work allocated to do it); I wasn't aware of the JetBrains plan (it's a nice plus, but I don't depend on it), and I'll probably do it as external files if the django core team itself is not interested, but I think it's more beneficial to do it inline.
One clarification is that there is no need to drop 2.7 support to use inline annotations; there's a python2 compatible way to annotate described now in PEP484. What I'd like to do is to get a reading of the room to see if there's some degree of interest (at least a "I'm curious to see how it looks if you do the work") before following up with the DEP process. I made a very quick summary of what I think the benefits would be, but if it's not clear I'd be happy to ellaborate. Some key things that have changed since last year (regarding the links posted by Florian and Tim) are: * PEP-484 is now approved and standard part of python. The mypy checker is now under the python project umbrella and getting active maintainance and backed by key people in the python community * Having a standard (instead of just a 3rd party tool supporting this) means that this now annotations can help to interoperate with many tools (type checkers, editors, documentation generators, refactoring tools), so the impact in the ecosystem is larger * There's some evidence that this works on production (people in dropbox have been using it for ~ a year, according to [1]) * There are several complaints telling that "this won't be actually optional", but I see no evidence to support it. And in any case those are arguments around deciding to include this in the language, and that decision has been made already. But in my experience, annotations help more in some particular modules/APIs and not in others, so an abvious option is to add them only where they add value (i.e. increase readbility and clarity of interfaces) * Cory Benfield points at some complex types, that (from a quick look) with new type aliases and overload semantics can probably be described in a much simpler and readable way. And again, if they don't that function (or that argument) shouldn't be annotated. * There's someone volunteering to do the work (me and some colleagues at Machinalis) :) I've already been looking at some interfaces in django and I feel that a lot of them are as not dynamic and polymorphic as requests is, so some success can be achieved here. So, how do you guys feel about this? what are the risks/fears that you'd like to have addressed? do you share my opinion that this will be positive for both the framework and its users? Best, [1] http://pythonpodcast.com/david-greg-mypy.html On Wed, Aug 17, 2016 at 2:41 PM, Tim Graham <timogra...@gmail.com> wrote: > The JetBrains announcement that they want to fund the project isn't a > guarantee that it'll be implemented. The feature needs to go through the > normal feature acceptance process, which as Markus said, might involve a > DEP. > > Assuming the idea is accepted, my sense on timing would be to wait until > January when Django drops support for Python 2.7 and 3.4 in master. Then we > could use inline annotations rather than the stub files. > > Past discussions of type hinting: > https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion > https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion > > On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner wrote: >> >> >> >> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote: >>> >>> @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 >>> ) >>> >> >> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ -- >> might be that things changed by now. >> > -- > 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/b5dcb500-4706-407f-8e42- > 65944d30ccf5%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b5dcb500-4706-407f-8e42-65944d30ccf5%40googlegroups.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/CALuYSZUopy0YHPgPZ%2BNgSk%2BKzNf8CpP-gdj2-CLXpicSNJ86Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
