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

131–140 of 237 posts

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

#131

Post by mehrdadn »

Waterluvian wrote: post #122
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.

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

So you think, for example, Numba (and everything that uses it) is misguided?

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

#132

Post by tigershark »

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.

Are you using notepad to write c#? If you hover on the var you will see the tooltip with the type.

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

#133

Post by joshuamorton »

sidlls wrote: post #127
joshuamorton wrote: post #126

Earlier quoted context omitted.

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

>The typechecker can't handle un-hinted code

And in Java or c++, un-hinted code couldn't compile. The python type checker can do more than a java or c++ checker in this regard.

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

They're exactly as silent or unknowing as you would get in typed python code. You appear to be comparing untyped python. That's an incorrect comparison. Offhand, I actually can't think of anything I could do in typed python that would get around the type checker, that wouldn't be considered reflection or a dynamic cast, and be very obviously so in python too. If you have an example of a silent or unknowing failure of well typed python code that passes on mypy, you should probably file a bug report ;)

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

You're right. Its not an answer not because I disagree with it (I don't), but because it doesn't actually answer anything, which is why I don't disagree with it.

To summarize this:

Python typecheckers are capable of more type inference than Java, and require less syntax than c++ or Java to get well typed code. A typed python codebase can interact cleanly with an untyped python codebase, and within the typed parts of the code, you get equivalent safety guarantees to what the type systems of Java or C++ provide.

Your appear to be ascribing magical powers to compilers in other languages, when those compilers have exactly the same type information as mypy does.

In other words, going back to your first statement:

>Hints don't provide any guarantees.

Hints provide exactly the same guarantees as any other type system: "Assuming you write reasonable code that doesn't attempt to subvert the type system, the type system will catch any dumb mistakes you make."

That's the exact same guarantee you get in any statically typed language.

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

#134

Post by Wehrdo »

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)

I'll bite.

  std::vector> in_order;
  std::transform(data.begin(), data.end(), std::back_inserter(in_order),
                 [](auto& item) {return std::make_pair(item.weight, item.name);});
  std::sort(in_order.begin(), in_order.end(), std::greater());
While I won't claim it to be as elegant as Python, it doesn't seem too ugly. Does anybody have an idea about how `auto` could be utilized to avoid the long vector type declaration?

For the adventurous: https://repl.it/repls/RepentantGentleKudu

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

#135

Post by tigershark »

c22 wrote: post #121
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.

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…

Between c and Python there is an ocean of languages...

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

#136

Post by jsjohnst »

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.

> forgotpassagan

They have password managers you know and also spell checkrs too. :P

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

#137

Post by jsjohnst »

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…

> Beyond that its utility diminishes until it starts to become a hindrance.

Tell that to any serious Numpy/Scipy/Pandas user.

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

#138

Post by joshuamorton »

nickelbox wrote: post #120
aub3bhat wrote: post #107

Earlier quoted context omitted.

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.

Sure, but at that point you've just reimplemented python in macros ;)

The other thing to note is that

    sorted([(k.weight, k.name) for k in somelist], reverse=True)
is essentially already typechecked:

    def biggest_ks(ks: K):
        return sorted([(k.weight, k.name) for k in ks], reverse=True)
The above code now has all the same type guarantees as your c++, actually maybe more since the macros you use are going to be...uhhh, mysterious.

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

#139

Post by tigershark »

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.

Absolutely not. Python is not the technological superior choice for the majority of the applications. If you think so then your experience in different domains and application types must be very limited.

The preconcept that dynamic languages are more productive is just an illusion because you can easily take shortcuts that will hamper your progress in the future. A proper typed language with HM type inference has the ability to mostly avoid writing the types with the guarantee that the compiler will catch most of the pitfalls. And if you don't do any logic error pretty much every time your code just works. Saying that in a million line application Python is a better choice than F# or Haskell it's frankly ridiculous in my opinion.

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

#140

Post by ambivalence »

Lxr wrote: post #124

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.

Since this is how gradual typing works, the goal is to annotate every last function.

Good question about abstract base classes! Paraphrasing a well known cliché: types in functions should be forgiving in arguments (what the function accepts) and strict in return values (what the function emits). In our case, the human reviewer needs to decide if the argument types collected by MonkeyType should be generalized. In fact, the collected types might not even work in all cases and the type checker might complain. It's because annotations describe "what should be" whereas MonkeyType finds "what is". This is why a system like MonkeyType shouldn't even attempt to use abstract base classes in place of concrete types that it collected.

Post reply on HN