Just a small update on this; I've published a first usable (well, I hope)
version at https://github.com/machinalis/mypy-django/ . It's stubs only,
although I'm basing it on an annotated django fork at https://github.com/
dmoisset/django/tree/typing . I covered some high-visibility APIs only
(request/responses, url routing, generic views), and some helper modules
that hose are built on (core.files, timezones, data structures).
I think it works, although while annotating the original code I struggled
with a few things:
- Some classes (most notably MultiValueDict/QueryDict) use inheritance
then break a bit the original interface. In that case I changed the
implementation a bit to use delegation instead of inheritance, so it's more
than "just adding annotations" in places like this. It still passes tests,
and I haven't run benchmarks but GvR suggested that the delegation version
is probably faster.
- There are some warnings thrown by the checker in the timezone module
that I'm not sure if they're because a bad specification or if those are
actual bugs (some methods like ReferenceLocalTimezone.utcoffset crash if
passed a "None" argument, but some examples seem to imply that a tzinfo
should accept it); there's no clear spec there. In the end I think this is
a good sign (this work will help identify some tricky/underspecified corner
cases in the API).
- The type stubs (annotations in separate files) allow to tell some "white
lies" about the API (for example saying @classmethod instead of
@classonlymethod because the latter confuses the typechecker). Those make
it more usable, but something will have to be done with that if integrating
annotations on the code is desired.
In general, the APIs in django seem to be much more structured than other
python stuff (like the requests example Florian mentioned
Feel free to comment and follow-up details on the project issue tracker. I
posted this update here in case it helps in the future to follow the
discussion about adding inline annotations.
Best,
D.
On 20 September 2016 at 16:24, Daniel Moisset <dmois...@machinalis.com>
wrote:
> Hey Graham. mypy has a structure to support multiple python versions as
> you noticed (and allows it to select them from the command line), but
> there's no mechanism for selecting library version. For me, supporting "the
> latest stable version" is a reasonable goal now. Flagging that
> appriopriately may become a problem in the future, but only if this
> succeeds, so I'm focusing on making this useful right now :).
>
> I already mentioned a naive approach (use different branches in the
> typeshed repo to support different django versions), but I'm keen to hear
> better ideas!
>
> And of course, if we get this into the django codebase itself the problem
> goes away (you get the annotations when installing django).
>
> Best,
> D.
>
>
> On Sun, Sep 18, 2016 at 9:00 AM, Graham Wideman <graham.wide...@gmail.com>
> wrote:
>
>> Just making note of the typeshed project https://github.com/python/type
>> shed, "Typeshed models function types for the Python standard library
>> and Python builtins, as well as third party packages."
>>
>> Pertaining to my earlier question about how pyi files should tell what
>> version of a library they pertain to:FWIW, typeshed uses directory branches
>> for different pyi files pertaining to different versions of Python, and
>> version-range conditionals within pyi files. These version-selective
>> devices pertain to version of Python. The interest in the discussion here
>> would relate to version of Django, of course, where it seems similar
>> measures might apply.
>>
>> --
>> 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/ms
>> gid/django-developers/5bf15a4b-8360-4ee0-a985-01f42e7e27fd%
>> 40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/5bf15a4b-8360-4ee0-a985-01f42e7e27fd%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
>
--
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/CALuYSZXoGXvhRtKkxLYsUEbmfza4PrsvCpqpwEtUJ2MhYKna4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
