Live data from Hacker News

Open-sourcing MonkeyType – Let your Python code type-hint itself

engineering.instagram.com

71–80 of 237 posts

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#71

Why didn't you make the Python 3 type checking advisory instead? Like what Facebook did with Flow and Hack, why not make write a product that lets you statically analyze the types and will never itself cause runtime errors, and transition to types that way? What advantage does building this tool have? I understand that the thing I'm describing involves modifying the way Python 3 handles type annotations, but it doesn…

I'm not quite sure what you mean. Python has an external static checker for types, it's called mypy. Python's type annotations are in fact very similar to Flow and Hack in the sense that they provide gradual typing. The specification (see: PEP 484) describes that only annotated functions are type checked. Calls to non-annotated code are treated as accepting any type in arguments and returning the Any type (a special…

> if you don't have enough functions annotated, the type checker won't be able to provide meaningful output to you

I too thought this but even just one check in a chain has been helpful to me.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#72

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

There's lots of good and bad things about Python.

The worst thing -- to me -- is dynamic typing.

So why not fix it?

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#73
post #60

Earlier quoted context omitted.

No, it's like asking someone who spent a lot of time building an octagonal wheel and is now trying to shave down the corners... why didn't you use a circle to begin with.

They did not spend a lot of time building an octagonal wheel, they built a billion dollar company using Python. Now, when the code base has been proven, and the business rules solidified, they retrofit what they believe will make the code base easier to maintain. Python is an excellent enabler of this kind of dynamic system evolution.

You've totally missed the analogy. See pfranz's comment.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#74

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

>>> but navigating a million lines of Python seems just daunting to me (although maybe I'm just not experienced enough with Python).

It's not that bad.

The first thing you learn when you're in a million lines codebase is that you will only work within your project of maybe a hundred files.

Once in a while, there is a guy who is asking for help on his project or there is an old weird bug to fix and you dive in other stuff. Otherwise, it's like it's not there.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#75
post #63
post #33

Earlier quoted context omitted.

>Is this done by purpose, or did they end up with a million lines of Python code and are looking for ways to make the maintenance easier? Definitely the latter. I've seen this discussion a few times before, and it's always the same. Your initial developers are not looking down the road to the million lines of code milestone, they're just trying to make a product that might actually make some money here and now. I'm s…

To add to this, note that type hinting is quite a new feature in Python (introduced in v3.5, released in 2015), and this functionality simply wasn't available before. So any company heavily invested in Python today obviously wants to improve their runtime reliability, without having to rewrite parts of their stack. Stricter typing goes a long way to achieve this, and gradual typing allows you to upgrade the code base…

Dropbox is very heavily invested in Python. I am under impression they hired Guido van Rossum to do exactly this, among other things. First 100% statically type the old codebase, then port it to Python 3.

You can statically type Python 2 codebases, but the language does not offer native support for it. Thus, all needs to go to docstrings or comments.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#76

Yet another hacky solution to address one of the biggest Python’s flaws. Why not switch to Java instead?

I was going to address the "why" by explaining actually why (Refactoring time required, impact difference, other negative tradeoffs, active devs on the projects / hiring requirements, benefit to the global python community, ...). But it looks like this is a troll account, so flag & move on.

[deleted]

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#77
post #4

"At Instagram we have hundreds of engineers working on well over a million lines of Python 3." It always amazes me that some of the most popular products around are built with the worst technology choices. And now they had to build their own static type checker, which slows down random samples of real users, just to shore up the language's weaknesses? Outstanding.

If lots of successful projects use what you consider the “worst” technology, perhaps the problem is with your perception rather than the technology?

That seems like a pretty dodgy metric. Lots of successful construction projects used asbestos, but it is still widely considered a mistake.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#78

Reading all of the comments from engineers who seem to either posess a time machine to send current tech back in time, or are criticising the technical choices that made the founders $squillions, is making me a bit mad. As a diversion perhaps some of them could list a few billion dollar startups that made perfect choices at the start and never had any cause to refactor or reimplement code as they grew?

It's not obvious (and IMO somewhat doubtful) that it was the technical choices of the founders that made them successful. Their choices could well have been bad, just not bad enough to make their business fail.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#79
post #37

Earlier quoted context omitted.

Isn't it faster to write everything in Go, for example, that has a compiler guiding you all the way and you rarely get runtime errors? I feel my developer time very much "optimized" when writing backends in Go than when I wrote then in Python (I also tried Node, which was a disaster).

Go wasn't a serious option for Instagram though. According to Wikipedia Instagram launched in 2010, Go launched in 2009. That would have made them very early adopters, was the library support there back then like it was for Python? Just because there may be better tools now, should they scrap their working code that earned their fortune?

I'm not talking about Instagram, I'm answering the parent comment, which talked about developer productivity in general.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#80
post #58
post #37

Earlier quoted context omitted.

Isn't it faster to write everything in Go, for example, that has a compiler guiding you all the way and you rarely get runtime errors? I feel my developer time very much "optimized" when writing backends in Go than when I wrote then in Python (I also tried Node, which was a disaster).

We're getting into a world where languages finally have type systems that dont suck for fast development. This wasn't the case until very recently. And many of the current options only became realistically viable in the last few years (or months!). We still have to work with the world as it exists. Not as it should be or will be. And even with the crop of modern languages, its often still faster to start with less op…

What are you talking about? Haskell is 30 years old.
Post reply on HN