I agree with you, but at some point, we could combine solid annotated core 
with a cut off for non annotated code? Otherwise, this will end up being a 
loop.

On Wednesday, 11 April 2018 17:16:21 UTC+3, dmoisset wrote:
>
>
>
> On 11 April 2018 at 11:21, Andreas Galazis <agal...@gmail.com 
> <javascript:>> wrote:
>
>> To me one approach would be to put a cut off for any merged code /PR  
>> start inlining type hints/annotations for all new code. This seems to 
>> simple to be a solution but at the end of the day as code gets updated even 
>> bigger part of the codebase will have type hints. The question is whether 
>> partial type-hinting is actually useful, but at least it supports heading 
>> towards the right direction.
>>
>>
> I don't think that approach will work. Partial type hinting is useful and 
> viable, but not randomly.... you need to do it bottom up (covering basic 
> abstractions first). So the place to start is probable the parts of django 
> that change less and are more solid foundations (in my case I started with 
> requests, views and URL resolvers, etc)
>
>
>
> -- 
> Daniel F. Moisset - UK Country Manager - Machinalis Limited
> www.machinalis.co.uk <http://www.machinalis.com>
> Skype: @dmoisset T: + 44 7398 827139
>
> 1 Fore St, London, EC2Y 9DT
>
> Machinalis Limited is a company registered in England and Wales. 
> Registered number: 10574987.
>

-- 
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/2d2a2ce3-23c7-4616-af48-52d2c1c6c866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to