Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sethmlarson.dev

Post reply on HN
Print view View original

41–50 of 205 posts

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

#41

Post by elzbardico »

jfabre wrote: post #28
david422 wrote: post #19

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.

This was probably just a silly example for a quick explanation.

  But all it takes is a method that expects an integer Id to receive a string representation of said id because of some obscure path in code that notwithstanding your 100% line coverage the team is so proud of, was never exercised on tests because nobody can have 100% branch coverage

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

#42

Post by cyral »

jfabre wrote: post #28
david422 wrote: post #19

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.

If only there was a way to enforce these parameter types automatically

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

#43

Post by papito »

Lack of type checking was a hot thing for a while. It made you "move faster". It was actually sold as an advantage. Until we realized that after moving faster you grind to a halt because now you have a massive codebase, with hundreds or thousands of files, and everything takes forever, and every change requires multiple rounds of testing.

I believe it really has to do with the size and complexity of modern projects. With a half-decent IDE you could sort of used non-type-checked Python in 2012, but times have changed, and now we are talking about statically checking Python and Ruby. And Javascript, of course, now has it in form of TypeScript.

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

#44

Post by ttymck »

wvenable wrote: post #34
david422 wrote: post #19

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…

The main argument for dynamic typing is speed in prototyping but I find that's opposite for me. I'm much more comfortable rapid prototyping and ripping stuff apart when I have a strongly static typed environment telling me what I just broke. Doing radical refactoring often involves just making those changes and then fixing all the IDE or compiler errors until it runs again.

I agree with your point on prototyping. I've never been more productive than when I have the (Scala) compiler acting as a second set of eyes, essentially looking over my shoulder, checking my business logic.

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

#45

Post by tunesmith »

dado3212 wrote: post #7

Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.

I've been a types advocate for years, but it wasn't until working with Typescript that I started experiencing some of the downsides...

To me, ideally, types are supposed to be a benefit not only in safety, but in understanding the intent of a piece of code more quickly. For an api or library interface, review the types to see what its intentions are.

But there's something about the typescript type system, with all the picks and keyof and typeof... sometimes it just feels like it's way too easy to go overboard, to the point that it occludes meaning. I understanding struggling with types if you're struggling with figuring out exactly what your boundary does and does not allow, but when you're struggling with types just because you're struggling with the kabillion different ways that some other typescript programmer chose to use the utility types... there are times when I feel like even Scala is easier.

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

#46

Post by cle »

malfist wrote: post #32
jfabre wrote: post #17

Earlier quoted context omitted.

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…

How in the world does type checking lower the ceiling on excellence?

I"m guessing by rejecting perfectly valid and correct programs that are unable to be type checked. There is a large space of "false negative" programs that a type checker will reject, but that could be perfectly correct. E.g. compare Python-esque duck typing with nominal typing.

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

#47

Post by sseagull »

kennywinker wrote: post #37
jfabre wrote: post #28

Earlier quoted context omitted.

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.

I've seen essentially this code in so many organically grown codebases (when they grew up without types). It's usually close the the UI, because someone had to quickly add an alternate path to support some new user interaction function find_user(person) { if user is string { query_by_name(person) } else { query_by_name(person.name) } } and yeah, we all know it's kinda messy, but also that logic has to live somewhere…

I came very close to writing almost this exact code just the other day (except it was username or user id for me), but came to my senses. It's just so tempting in a dynamic language...

In a static language, you either can't do it, have to really go out of your way to do it, or at least do function overloading (which is a bit cleaner)

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

#48

Post by Enginerrrd »

wvenable wrote: post #34
david422 wrote: post #19

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…

The main argument for dynamic typing is speed in prototyping but I find that's opposite for me. I'm much more comfortable rapid prototyping and ripping stuff apart when I have a strongly static typed environment telling me what I just broke. Doing radical refactoring often involves just making those changes and then fixing all the IDE or compiler errors until it runs again.

Dynamic typing was great before I knew anything about programming. I'm talking like, at a middle school level. Fewer "Silly" errors.

After university, the opposite became true. No difficult to diagnose undefined behavior because of ambiguity in typing.

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

#49

Post by freemint »

kennywinker wrote: post #37
jfabre wrote: post #28

Earlier quoted context omitted.

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.

I've seen essentially this code in so many organically grown codebases (when they grew up without types). It's usually close the the UI, because someone had to quickly add an alternate path to support some new user interaction function find_user(person) { if user is string { query_by_name(person) } else { query_by_name(person.name) } } and yeah, we all know it's kinda messy, but also that logic has to live somewhere…

Sounds like a brilliant case for multiple-dispatch.

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

#50

Post by kzrdude »

tester756 wrote: post #4
gundamdoubleO wrote: post #2

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.

It's $current_year and there's still debate whether checking stuff at compilation time is better than at runtime?

That's not really the debate in Python :)

Almost every Python user now has to "deal" with type annotations. It's tempting to gradually add type annotations, it's nice documentation.

But it also rubs me the wrong way to have annotations that are never checked(!). In many codebases, you might just have "casual" style type annotations in Python, and nothing ever asserts that they hold. That's nagging on me, a bit.

Post reply on HN