Static type checking for public API

[John Michael Lafayette]

Python now has static type checking. All you do is follow function parameters with ": paramType" and add "-> returnType" before the colon at the end of the function declaration and auto-complete will work on the return value in IntelliJ. Can you add the function parameter types and return types to all the functions in the public API?

> So like change this...
> def func(param):
>
> To this...
> def func(param: int) -> str:

That way when I call a function, the static type checker will make sure I pass in the right type.

[Collin Anderson]

Hi John,

I think we need to wait until we drop Python 2.x support to be able to do this, as 2.x won't accept this syntax. Does that sound right?

Thanks,

Collin

[Donald Stufft]

It supports a mode that is comparable with Python 2.x, but which isn’t as nice. You essentially need to ship additional stub files that just have the type hints in them.

--
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.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81f6b5a2-14a2-4a7a-82c4-74d3016ff59f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-----------------

Donald Stufft

PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[Florian Apolloner]

No we can't (at least not till we drop python 2). You are free to write your own stub files though, this can easily live as a separate repo for now imo…

[Aymeric Augustin]

Hi John,

In case that’s not clear from the answers above, your question roughly translates to “can you do dozens of hours of very boring work and increase your maintenance workload in the future for no discernible benefit to you, just because I ask?” There’s no way that could be met with a positive response.

If you want maintainers to participate in a discussion rather than just find an excuse to brush away the idea, I suggest to say “hello”, explain why you think it’s appropriate for Django to embrace this feature, argument why its benefits are worth the added maintenance cost, and offer to implement it.

I hope this helps,

-- 

Aymeric.

--
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.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d4ad3ff3-904c-4419-9759-a71ba9aa0f32%40googlegroups.com.