Agree. January is not that far out, and then you get to build the annotations as designed in the PEP. You can begin work earlier of course, but keeping your patch up to date with all of the work going on may become annoying. The HttpRequest/Response objects don't really get changed that often so it merge conflicts might not be that big of a deal in practise.
I'm probably in favour of the idea in general. There are many internals in django that would benefit from documenting inputs and outputs - if only for the people working deep within the guts. I understand those parts probably wouldn't be targeted first, but as new patches come in, we can begin making those annotations gradually. I do have some concerns about providing typing information where importing type names would normally cause import cycles. How is that addressed? I admit to not really following the typing hint features very much so I'm a bit naive here. Thanks, On Thursday, 18 August 2016 00:47:31 UTC+10, ludovic coues wrote: > > Dropping support for python 2.7 has been planned for some time. Django > 1.11 will be the last one supporting python 2. The following release > will be django 2 and will only support django 3.5+. See > https://docs.djangoproject.com/en/dev/releases/1.11/ > > That's what Tim was talking about. You can target inclusion in django > 2 and forget about the quite uglier #type comment. > > 2016-08-17 16:13 GMT+02:00 Daniel Moisset <dmoi...@machinalis.com > <javascript:>>: > > 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 <timog...@gmail.com > <javascript:>> 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-develop...@googlegroups.com <javascript:>. > >> To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > >> 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. > > > >> > >> 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-develop...@googlegroups.com <javascript:>. > > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > > 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. > > > > -- > > Cordialement, Coues Ludovic > +336 148 743 42 > -- 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/f3be2364-0a42-4b56-b274-662cb0833e76%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
