Live data from Hacker News

Python types have an expectations problem

medium.com

111–115 of 115 posts

Re: Python types have an expectations problem

#111
post #109

Earlier quoted context omitted.

If you don't test the behavior of your code then it is wrong. Whether the code could in theory be compiled isn't a very good test case. Static type checking has a measured bug catch rate of <1%. So the quality of any code where the programmer depends on static typing to verify correctness rather than unit tests is very very low.

Measured by whom?

Various academic studies on the topic

Re: Python types have an expectations problem

#112
post #109

Earlier quoted context omitted.

Measured by whom?

Various academic studies on the topic

Such as?

Looking forward to a set of paper from renowned researchers with SIGPLAN/ACM, IEEE proven credentials in language research.

Re: Python types have an expectations problem

#113
post #98
post #38

Earlier quoted context omitted.

Nope. See https://bugs.python.org/issue45117

Yep. This is explicitly what I listed as "as long as you don't (a), evaluating at runtime". This extremely specific and rare case is outside of the scope of "Generally, this works". It means that some, very few definitions still need to be in old style, but the majority of your code is fine.

I didn't say you couldn't make it work by writing it differently. The point was obscure errors can pop up, which is a drawback to the way they chose to do things. That holds.

Re: Python types have an expectations problem

#114
Sorbet is a really interesting point in this space, because in addition to its static type checker, it has a runtime component which can do runtime type checking.

It installs shims around all your methods which type check arguments on the way in, and results on the way out. Of course this comes with a performance penalty, so it’s often enabled for development and testing, but disabled in production.

Re: Python types have an expectations problem

#115
post #93

Earlier quoted context omitted.

I previously worked at Dropbox, which had server codebase consisting of over 2 million lines of (untyped) Python. While I was there, Dropbox introduced type annotations into the codebase and used it as a testing group for Mypy, which was being developed largely at Dropbox, with both Jukka Lehtosalo and Guido van Rossum on staff. I can say from that experience that pretty much everything you are claiming is wrong. Dev…

I've seen both the statically typed Python 1Mloc monolithic and the ducked typed 1Mloc micro-service based approach in practice. I'm telling you the ducked typed micro-service based approach is the way to go. But you sort of know that "not to write a 2Mloc server in Python", don't you? If we encourage developers to use static typing they will be writing 2Mloc monolithic servers. That's just the type of code that stat…

Yes, I said quite clearly not to write a 2Mloc server in Python. Honestly, I would lean towards not writing servers of any size in Python, but if scalability and performance are of low concern, it could be a productive language for certain apps.

"If we encourage developers to use static typing they will be writing 2Mloc monolithic servers."

I don't even know where to begin with this wild assertion. Ill-advised as it was, Dropbox wrote its two million line server long before typed Python even existed. I wasn't around when they started cracking it up (see blog post below), but I strongly suspect the type annotations in the codebase helped rather than hindered that effort.

https://dropbox.tech/infrastructure/atlas--our-journey-from-...

Post reply on HN