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

111–120 of 237 posts

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

#111

Post by arbie »

forgotpassagan wrote: post #105
btown wrote: post #104

Earlier quoted context omitted.

They say there is a holy land called Haskell, but it is only revealed to the truest of believers without the weight of the chaotic-neutral entity “Shareholder” weighing ever so heavily on their shoulders. For those in Shareholder’s clutches, one must forgive their prayer. ‘Tis the best they can do.

There is something else, in the darkest reaches. It has many incantations, but the non-believers have a singular name. Lisp.

With it's comforting, reassuring warmth, Perl shines on as a luminous sun, lighting the way for youngling languages to learn from. Hushed whispers foretell the sunset, but none truly believe them...

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

#112

Post by sidlls »

ageofwant wrote: post #99
tjoff wrote: post #92

Earlier quoted context omitted.

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.

I think the general consensus is that that is not true. Python's dynamic nature is a clear advantage it has over statically typed languages. Add the fact that you can elect to tune down the dynamism when it makes sense to with very little impact on your existing stack makes Python the technological superior choice for the majority of applications.

There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception).

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 is a good choice to prototype, write small (less than a few thousand lines of code) projects with non-trivial complexity, and somewhat larger projects with more boilerplate (e.g. Django webapps). Beyond that its utility diminishes until it starts to become a hindrance.

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

#113

Post by klipt »

toast0 wrote: post #103
IshKebab wrote: post #69

Earlier quoted context omitted.

Navigating a large code base that is dynamically typed like Python is far more tedious than something like C++ or C#. First you can't read what the types passed into and out of functions are. You have to find their usages to work it out. Second, you can't reliable do things like "find usages" or "go to definition" because of the dynamic typing.

Most of the c++ and c# code I see lately has so many things declared as auto, it's hard for me to figure things out too.

Would be nice if IDEs had a key combo to fill in the actual type for "auto"s!

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

#114

Post by sidlls »

oblio wrote: post #101
hacker_9 wrote: post #32

Earlier quoted context omitted.

The evolution is fairly simple: python is very easy to setup, especially with django for working on the web, and for writing scripts quickly it work really well when everything is just an 'import' away. Then as the product gets bigger, you'll hire python developers to keep up with the workload - and the best ones will be the ones who have committed their lives to Python. So you'll now end up with more and more python…

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.

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

#115

Post by Yxven »

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…

Personally, I would love to ditch python for a language with strong types and type inference, but what is the replacement for django? Where do I find a well-designed, well-documented, battle-tested framework that I can easily hire developers for?

Currently, I think the nearest competitor is node with typescript, and I'd rather stick with python. Please tell me if I'm wrong.

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

#116

Post by joshuamorton »

sidlls wrote: post #112
ageofwant wrote: post #99

Earlier quoted context omitted.

I think the general consensus is that that is not true. Python's dynamic nature is a clear advantage it has over statically typed languages. Add the fact that you can elect to tune down the dynamism when it makes sense to with very little impact on your existing stack makes Python the technological superior choice for the majority of applications.

There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception). 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…

>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 time, you get all of the advantages that python has over statically typed languages that aren't haskell (like comprehensions). And, when you need to, if you're doing something that's especially tricky or dynamic or whatnot, you can fall back to untypedness.

I think the closest parallel I can draw is to something like Rust. You get a huge set of guarantees for free, but can opt to do unsafe things when it's absolutely necessary, and better yet, you can start in unsafe land and then go back later and make sure your code is safe.

I'm curious what tooling you feel that say, Java, has over type-annotated python.

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

#117

Post by sidlls »

joshuamorton wrote: post #116
sidlls wrote: post #112

Earlier quoted context omitted.

There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception). 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…

>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 does.

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

#118

Post by swsieber »

jimnotgym wrote: post #59

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?

Whatsap? Just kidding, they probably had to refactor code too. But their technical story seems a lot better than most startups

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

#119

Post by viraptor »

sitkack wrote: post #106

As both a dynamic and static type enthusiast, back typing dynamic code is extremely problematic. Fluent use of a dynamic language will use and create constructs that are nearly un-typeable. If you want to make typed code, start typed. If you code with implicit types, use a good type inferred language (ML, F#, etc). If you want to use type checking in Python, use the annotations and MyPy from the beginning. That said,…

> Fluent use of a dynamic language will use and create constructs that are nearly un-typeable.

Do you mean cases where you accept "anything iterable", an issue with callbacks / template types, or something else?

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

#120

Post by nickelbox »

aub3bhat wrote: post #107
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…

Please show me C++ equivalent of sorted([(k.weight, k.name) for k in somelist], reverse=True)

You could implement the following with a decent bit of work (declaring k and reversed to be variables of special, hand-written/macro-generated types with overloaded operator, and operator=).

sorted( (k.weight, k.name).for_(k).in(somelist), reverse=true));

You would never be able to get that past code review, however.

Post reply on HN