News for hackers. Stuff that matters.

A comment on Python at Scale: Strict Modules. Parent comment

Re:Python at Scale: Strict Modules by matesz on Friday December 18, 2020 @06:41AM (#25466134)
In our case biggest problem arose with Pandas, where each dataframe transform would need to have it's own type. When there are a lot of transforms it is more readable to infer what type variable has just by looking at transforms (more or less) or when needing to be precise step through the code with ipdb/jupyter etc.

What about incremental typing? That's what we did, and to be honest I wouldn't do it again. Yes, it's nice to see what type function is returning/arguments it's accepting, but if the name is shit type won't tell you much - you are better off spending more time of figure out better naming convention (prepend dataframes with df_ for example) and keep at it.

Another problem with incremental typing is that now of course you will have to decide whether to annotate/not annotate, and when reading code thinking why this is annotated and that is not annotated.

[ Parent | on HN ]
Re:Python at Scale: Strict Modules by giantDinosaur on Friday December 18, 2020 @07:28AM (#25466418)
Right. Similar problem to Typescript - generally its best users are those already sold on static types, for many others the temptation of <any> and friends is too much, and interacting with untyped/poorly typed libraries + poor type inference can be really frustrating. Although in that case it's still a massive gain for new projects, in my experience.
[ Parent | on HN ]