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

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

engineering.instagram.com

Post reply on HN
Print view View original

121–130 of 237 posts

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

#121

Post by c22 »

tjoff wrote: post #92
depressedpanda wrote: post #88

Earlier quoted context omitted.

No, I the analogy just wasn't very apt. Python allowed them to build a successful company. Now, when their stack is mature and maintenance is more important than rapid prototyping, Python allows them to add type hinting. Because they are engineers, they built a tool (in Python) that allows them to do it in an automated manner. And all of this is great! They are evolving their code to fit their needs; it's nothing lik…

The point is that there is no property of python that allowed them to build a successful company that any statically typed language don't have. It is a completely unnecessary detour. The cost of doing it right from the start is negligible.

The first language I learned (after Applesoft BASIC) was C. I wrote C for a long time. About 6 years ago I picked up Python. Today I find it much easier and much more pleasant to spin up a new idea in Python, to the point that it is my default choice for new projects with fuzzily defined goals. None of my ideas have become companies, but I could totally see just sticking with Python even past the point that it became unwieldy.

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

#122

Post by Waterluvian »

Cieplak wrote: post #41

Given that people have asked why not use a statically typed language, seems appropriate to mention that it's possible to write pythonic-looking C++: http://preshing.com/20141202/cpp-has-become-more-pythonic/ I have been using C++ a lot lately but really wish there were more tools for reflection at compile time, e.g., ability to iterate over all the members of a class. Other than that, I'm really loving C++17's auto t…

That's kind of missing the point though. Languages are tools for different purposes. You may love chizels and lathes and saws but you wouldn't build a suspension bridge with wood. Just like I wouldn't build a cabinet with cement, steel, and rebar.

Picking C++ over Python is like picking woodworking over metalworking.

Python being slow is never an issue unless someone is insisting on using the wrong tool for the job.

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

#123

Post by scrollaway »

sidlls wrote: post #114
oblio wrote: post #101

Earlier quoted context omitted.

Rewriting a whole app would be at least as big of an investment, in my opinion...

But not as useful for the resumes of the devs involved.

Did it occur to you that rewriting an internal app has no benefit to the community at large, whereas publishing a tool is a clear improvement on the community's tools?

Did it occur to you that instagram published a valuable and useful tool that now just exists, and this is now a non-issue for anyone else in their situation?

Like, why are you complaining about resume boasting?! It's like you want people to do useless work that has no positive effect on the open source community. Are you just upset people are using Python or what?

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

#124

Post by Lxr »

Is their goal to annotate everything or just the non-obvious things? Also how would a tool like this handle cases where the “correct” type is a generic base class but at runtime it only sees a certain subclass? To be pythonic, a function that accepts a tuple should usually also accept a list for example, but at runtime that may never happen.

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

#125

Post by sidlls »

maltalex wrote: post #13

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…

Rewriting over a million lines of code in a statically typed language coming from one likely as riddled with type errors as this codebase is is unlikely to be productive. They're making the best of a terrible situation.

I also think that if they want to use types the correct approach is to apply a tool like this as a stop-gap but write new components going forward and bug fixes/feature re-writes in a language that supports types "properly" (i.e. in the way they seem to want, that is static types checked at compile time).

I think tools like this are great for companies in situations like this. I don't think they're good to use from the outset: the team should just use an actually statically typed language instead.

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

#126

Post by joshuamorton »

sidlls wrote: post #117
joshuamorton wrote: post #116

Earlier quoted context omitted.

>Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take advantage of that? Python's type system is, imo, currently better than Java's, and the syntax is cleaner than java's or C++s. You get all the benefits of static typing without having to put `auto` and `List ` everywhere. And at the same ti…

Hints don't provide any guarantees. It's still possible to silently and unknowingly pass the wrong type of value into any given argument, with or without the checker. The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to. "What do you think these checkers do?" you might ask. The answer is: not nearly what a compiler doe…

> It's still possible to silently and unknowingly pass the wrong type of value into any given argument

This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection. Much like its exceedingly unlikely that you'll run across this in "normal" java or C++, its exceedingly unlikely for you to run into any issues with this in python. And, in fact, the typechecker has ways to handle unusual things like dynamically created attributes, for when that comes up.

And yes I mean this quite honestly. I've seen a lot of typechecked code, some of it quite ridiculously dynamic. Typecheckers perform absolutely fine.

>The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to.

What way is that? Typechecking is static analysis. There's really no difference between how java or cpp does typechecking and how mypy does, other than that the python typechecker isn't installed by default.

>The answer is: not nearly what a compiler does.

This is not an answer.

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

#127

Post by sidlls »

joshuamorton wrote: post #126
sidlls wrote: post #117

Earlier quoted context omitted.

Hints don't provide any guarantees. It's still possible to silently and unknowingly pass the wrong type of value into any given argument, with or without the checker. The "tooling" the other languages have includes a compiler that performs these checks in a way that Hints + Checker-of-choice is unlikely (or unable) to. "What do you think these checkers do?" you might ask. The answer is: not nearly what a compiler doe…

> It's still possible to silently and unknowingly pass the wrong type of value into any given argument This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection. Much like its exceedingly unlikely that you'll run across this in "normal" java or C++, its exceedingly unlikely for you to run into any issues with this in python. And, in fact, the type…

> This is also possible in traditionally statically typed languages. Nothing stops you from doing unsafe casts or using reflection.

Neither of those is "silent" or "unknowing".

> What way is that? Typechecking is static analysis. There's really no difference between how java or cpp does typechecking and how mypy does, other than that the python typechecker isn't installed by default.

The typechecker can't handle un-hinted code (or, rather, it chooses something very permissive, like 'Any' for all hints). It's incomplete at best.

> This is not an answer. It is. That you don't like or agree with it doesn't make it not an answer.

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

#128

Post by BucketSort »

I come from a statically typed background (C++), but have been doing a lot of analytics in python in the past two years. It is frustrating not to have compile time guarantees when dealing with mathematical programs, because some things have to be a particular type (i.e. matrices of compatible dimensions). The result is a copious use of asserts, but it feels bad when you know that if you did this in a functional language,let's say, you could prove implementations are correct by the nature of the type system. In short, I'd love to see more strong type support in python.

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

#129

Post by AlexCoventry »

user5994461 wrote: post #74
maltalex wrote: post #13

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 s…

Sounds like the projects you worked on had excellent encapsulation.

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

#130

Post by AlexCoventry »

thechao wrote: post #25
alsadi wrote: post #9

Earlier quoted context omitted.

Those people believe that the right choice is assembly unless you can write directly in hex /s

I was taught assembly at the job by an old assembly guru. His first statement to me was something along the lines of: "we'll use an assembler to start with, but it doesn't generate very good code; so, once you're comfortable, we'll hand assemble our machine code".

Was he just messing with you? What's a case where assembly is not isomorphic to machine code?
Post reply on HN