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

71–80 of 205 posts

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

#71

Post by inertiatic »

kzrdude wrote: post #50
tester756 wrote: post #4

Earlier quoted context omitted.

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.

Never checked? They're statically checked.

Also, tooling like https://pydantic-docs.helpmanual.io/ can do runtime checking for important parts of your app or you can use this https://github.com/agronholm/typeguard to enforce all types at runtime (although I haven't measured the performance impact, probably something to do in a separate environment than production?).

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

#72

Post by fiddlerwoaroof »

lemper wrote: post #16
fiddlerwoaroof wrote: post #8

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 a small side project in clojure [1] and i always miss type checking when working on it. not by much because it's a small project but i am tired of iseq is not a function error. [1] https://dactyl.siskam.link

I sort of think there are two mindsets behind this debate: people that miss the guard rails of a static type system and people that enjoy the experience of iterating quickly in a dynamically typed language. I don't really want to say everyone should pick one side or the other, just that my experience doesn't bear out the claim that "statically typed languages produce more maintainable code". And, the little bit of empirical evidence for this proposition is largely inconclusive: https://danluu.com/empirical-pl/

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

#73

Post by kzrdude »

inertiatic wrote: post #71
kzrdude wrote: post #50

Earlier quoted context omitted.

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.

Never checked? They're statically checked. Also, tooling like https://pydantic-docs.helpmanual.io/ can do runtime checking for important parts of your app or you can use this https://github.com/agronholm/typeguard to enforce all types at runtime (although I haven't measured the performance impact, probably something to do in a separate environment than production?).

They are statically checked, if you run a type checker. Which many don't.

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

#74

Post by taeric »

Zababa wrote: post #58
taeric wrote: post #20

Earlier quoted context omitted.

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…

The metaphor doesn't really works, as in software lots of high rise start as a little shed.

Quite the contrary, in my opinion. Lots of what makes various parts of the physical hard are in the infrastructure surrounding them. This is very similar to the complexity in software setups.

Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games.

Similarly, look at the general practices around building and maintaining bridges in physical world. We call all bridges by the same name, but reality basically dictates that what works in some locations cannot and will not work in others.

Now, you are right that we can grow large software out of smaller in ways that the physical can't do. But, it is a common fallacy to stall out a project by trying to be at google's scale from the start. Ironic, in many ways, as not even google was built to be at their scale from the start.

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

#75

Post by andybak »

Having spent a decade with Python and more recently a few years with C# I still can't quite put my feelings into words but here's an attempt:

"The benefits of explicit typing are obvious and clear but they downsides are subtle and hard to communicate"

I still think typing in general is a net win but I'm not sure whether static typing is. You find yourself writing code that just wouldn't be neccesary in a dynamic language - and I don't just mean the direct code you write to declare and cast types. There are more subtle costs.

I need to spend time with a good type inference in a language with modern typing and dynamic features to sort out how I feel about this.

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

#76

Post by layer8 »

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 hate having to waste time figuring out the type of every variable and hold it in my head every single time I read a piece of code.

For the same reason, I’m not a fan of type-inferring variable declarations.

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

#77

Post by mwcampbell »

jfabre wrote: post #17
fiddlerwoaroof wrote: post #8

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…

> Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence.

At 40 years old, I've seen enough of my own incompetence that I'll gladly accept things that can mitigate it. As for excellence, I suppose static typing would have prevented a handful of clever hacks that I did in Python and Lua when I was in my 20s, 12+ years ago. Truthfully though, my memory of that period has faded enough that I'm not sure, and I doubt that any of those hacks were crucial for the products that I was developing at that time. Yes, a type system as primitive as Java's at that time would have felt like a straitjacket. The same might have also been true for C#. But modern static type systems are much more flexible, and I don't think I've rejected a language based on its static type system in the past several years. (I've recently done a project in Elixir, but that was despite its dynamic typing, not because of it.)

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

#78

Post by DylanSp »

adrianmonk wrote: post #65
handrous wrote: post #18

Earlier quoted context omitted.

> 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 see static types as one of the most powerful communication tools around, as far as code goes. I can't relate at all to people complaining that they waste time. They must work very differently from how I do, is all I can figure. It's that, or they don…

Consider these 4 possible combinations for programming languages: (1) Low-level, static types (2) Low-level, dynamic types (3) High-level, static types (4) High-level, dynamic types For whatever reason, historically #1 and #4 have been most popular. C, C++, Pascal, Ada, and Java are #1. Python, JavaScript, Perl, and BASIC are #4. There haven't been a lot of #2 or #3 languages. Some #3 languages (TypeScript and Python…

I don't really see how Java is closer to C than it is to Python in terms of what level of abstraction it's working on, could you elaborate?

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

#79

Post by shrimp_emoji »

zz865 wrote: post #35
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 feel the same way but wonder if I'm right when the majority of jobs are JS and Python.

Both of those languages' communities have essentially admitted that not having type checking was a mistake and try to patch it with TypeScript and MyPy.

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

#80

Post by tus89 »

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…

Yay -- maintaining type definitions for arbitrarily complex nested dicts/arrays that are often built up when processing data and in all manner of different ways.

You know why "Any" appears in Typescript so much?

I doubt anyone here is an actual programmer, if you were you would understand that having to define type definitions for "objects" that are often just parsed from JSON API responses or constructed through the processing of data is the biggest pain in all languages, and why typeless languages are convenient and popular for this kind of work.

Oh and then the API response changes slighty, breaking your type definition, whereas typeless Python keep chugging along because it is very tolerant of small changes to underlying data, especially if written in a defensive manner.

If you want types, why are you using Python at all? Go write bloated Java/.NET that takes a team of 10 six months to put together a simple app that would be written in week in Python.

Post reply on HN