And how would you describe your political tendencies? I have a theory that more MLs are gonna be into static typing and more anarchists are gonna be into dynamic typing.
And how would you describe your political tendencies? I have a theory that more MLs are gonna be into static typing and more anarchists are gonna be into dynamic typing.
I use it everywhere because type hinting allows pylance to infer the type of a return value and let's you use the IDEs autocomplete functions
Sure, but most of the code that is not complex is very straightforward and a lot of it is just using
dictso it's just getting/setting via thefoo['bar']syntax so autocomplete isn't really helpful. Like I said the more complicated parts that have complex objects is where the real benefit isIf you're calling any methods on the values stored in those dicts it's still pretty useful. But if it's all primitive types then it's not going to help.
In our case it's all primitive types since we're mostly dealing with web inputs from Django, and then some Celery tasks for RPC and we use primitive types for the arguments because it's a simple data, complex operation kind of application
It also tells you what type is expected by a function if you set up Pylance right. Which means you're able to just mousehover on a function and see exactly what type it requires for each parameter and what type it returns.
That also lets other functions that use that function infer the return type and continue to offer syntax highlighting and code completion.
If you have an un-hinted return type, then it won't automatically highlight the primitive functions you can use.
It's absolutely not necessary, but it makes reading code so much easier later when everything i need to know it hinted at right there in the function call.
Most of the code that is being written is view classes or form classes for Django, so really there's not a lot of times where we are writing code directly that references those where autocomplete matters. Like, a great deal of our code is in
form_validmethods and you never call those in your code, the framework calls them.Same with Celery, where we have the code for the workers in a separate repository and we are calling
send_taskinstead of having aSignatureto directly callapplyonThat's fair, I'm usually writing a ton of tools and such from scratch and using an API for a very popular GIS software where getting those objects recognized properly saves me tons of headaches debugging because I now know I have a Point Geometry object and not a Point object based on proper type hinting in my utility functions.
Also means if I write some function that required a Point Geometry object and a Layout object to work, I can put it in the docstring and also type hint it so other programmers in the office are able to really quickly tell exactly what they need to provide for the function to work.
It's nice to have in that really rapid development situation for sure, my commits and changes usually have a 10-20 minute turnaround to get things working since everyone in production is using my main branch. I have all the other devs working on forks so they can isolate their code from the central repo that everyone is always referencing for their tools.
When you only have 5 minutes to debug a production tool, having a ton of built in links to the bajillion different methods Arc objects have is necessary.