Live data from Hacker News

Tests aren’t enough: Case study after adding type hints to urllib3

sethmlarson.dev

21–30 of 205 posts

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#21

I've seen a lot of push back on adding type checking to Python but we had a similar case at my company where we tried it out on a new project and the clarity and readability of the code was immediately beneficial to the entire team. Perhaps it's something well suited to larger codebases.

I want type checking on pretty much anything that will ever exceed about two screenfuls of code. If I can't keep the whole thing in my head at once, I want the computer to do it for me. That's the point, right? Making computers do stuff for us so we don't have to?

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#23

I love static typing/type hints if for only 1 thing - code maintenance. Even code I wrote six months ago. Not having to dig through 6 functions deep to try to figure out whether "person" is a string, or an object, and if it's an object what attributes it has on it etc. is huge. And not to mention that some clever people decide - hey, if you pass a string I'll look up the person object - so you can pass an object or a…

This is absolutely how I feel. I've mentioned previously taking over a project, and just not knowing the type of anything took me months to overcome.

Also, type hints really help your IDE, even catching errors before you even run tests.

There's also a visual cue that you are doing something wrong: If a function returns 4 levels of Union[Tuple[List[int]], Optional[str]........ Then you are doing something too complex and the function should be broken up.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#24

I've seen a lot of push back on adding type checking to Python but we had a similar case at my company where we tried it out on a new project and the clarity and readability of the code was immediately beneficial to the entire team. Perhaps it's something well suited to larger codebases.

Just wish Python's typing was better. But it's impossible to type hint the crazy "pythonic" code out there. Like the kwargs used to do a Django query.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#25
post #20
post #11

I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has taken for granted for decades - type-checking, immutability, unidirectional data-flow, AOT-compilation, closures, pure functions, you name it. I'm glad we seem to be converging on a set of best practices as an industry, but sometimes I wish we were spending less…

I've been alive long enough to see that most things are useful, and all things are oversold. More, the nice easy things to build with major restrictions pretty much gets thrown out the window for complicated things that have constraints that most efforts don't have. This isn't just a software thing. Building a little shed outside? Would be silly to use the same rigor that goes into a high rise. Which would be crazy t…

Not that I disagree, but I feel like you are overselling the simplicity of [building a shed](https://en.wiktionary.org/wiki/bikeshedding).

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#27
post #17

Earlier quoted context omitted.

I’ve done everything from Haskell to Java and I still strongly prefer Clojure and Common Lisp-style dynamic types.

I have to agree, I've done over 5 years of C# and then went to ruby and never looked back. Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence. I have to admit I don't have experience with the extremes which would be Haskell and Clojure. The amount of cruft I had to type in C# just to get shit done... It's all implicit in ruby thank god for that. I never EVER have to check…

> I always know its type just by looking at its name. Is it enforced in ruby? Of course not. Ruby assumes I'm an adult and I know that I'm doing.

TIL taking notes of things you want to be reminded of in the future is for children and the incompetent.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#28

I love static typing/type hints if for only 1 thing - code maintenance. Even code I wrote six months ago. Not having to dig through 6 functions deep to try to figure out whether "person" is a string, or an object, and if it's an object what attributes it has on it etc. is huge. And not to mention that some clever people decide - hey, if you pass a string I'll look up the person object - so you can pass an object or a…

I never understood this argument. In what kind of shop are you working that passing a string named person to a method expecting an object is tolerated. Or even passing different types that don't share a common interface.

This would never fly in a code review in any of the companies I've worked for.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#29
post #11

I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has taken for granted for decades - type-checking, immutability, unidirectional data-flow, AOT-compilation, closures, pure functions, you name it. I'm glad we seem to be converging on a set of best practices as an industry, but sometimes I wish we were spending less…

Yes, and when that ecosystem discovers these obvious facts, the discovery is always described as a "journey" in the accompanying blog post. Having sense and good taste at the beginning of a project doesn't warrant a blog post but slowly stumbling over isolated aspects of good taste, now that's a journey.

Re: Tests aren’t enough: Case study after adding type hints to urllib3

#30
post #11

I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has taken for granted for decades - type-checking, immutability, unidirectional data-flow, AOT-compilation, closures, pure functions, you name it. I'm glad we seem to be converging on a set of best practices as an industry, but sometimes I wish we were spending less…

Programming is sufficiently complex field that we can find examples when the opposite things are the best: it depends on context whether you need more or less types.
Post reply on HN