
MonkeyType: A system for Python that automatically generates type annotations - chenzhekl
https://github.com/instagram/MonkeyType
======
Bnshsysjab
While I really like type annotations I hate that they’re little more than IDE
hints.

There’s nothing to stop calling functions with incorrect datatypes at runtime
and I’d consider this one of the single biggest weaknesses of python right now

~~~
BiteCode_dev
The fact you can rely on every API to allow duck typing is a core feature of
the language. It has pros and cons, of course, like all features. But it is
not an accident, it's by design.

And type hints have been designed with this in mind. It will stay that way.

If this is feature makes you unhappy, Python will make you unhappy. It's
important to know what are the values that are important to you and chose your
toolbox accordingly.

~~~
nick_meister
Isn't Python just a language? AFAIK there are many Python interpreters (or
implementations), like CPython, Jython, IronPython,....

Couldn't a Python interpreter enforce type checking and raise errors whenever
a type doesn't match? I'd be happy to use such an interpreter in many
scenarios.

~~~
guggle
Tons of libs wouldn't work this way I guess, probably including stuff in the
standard library. So you could really just use a subset of the Python
ecosystem. I'm not sure it's worth the effort.

~~~
dharmab
The standard library tends to work pretty well in general, but common
libraries like boto will have problems.

------
heavenlyblue
What are your thoughts on purely static tools on that for Python?

Basically my latest project that I was thinking about is to write a symbolic
executor for python that would simply preserve all of the required-type
information for all of the execution paths of the program.

Also the other project is to write a tool that allows you to walk all of the
possible executions of a given piece of code to find which functions are being
called from it - incredibly useful for refactoring of the old code.

Does something like this exists already that you've used and found useful?

~~~
BiteCode_dev
I'm not sure, but maybe you can have a look at the following projects to have
an idea of prior art:

\- jedi:
[https://github.com/davidhalter/jedi](https://github.com/davidhalter/jedi)

\- nuitka: nuitka.net/

\- python language server: [https://github.com/palantir/python-language-
server](https://github.com/palantir/python-language-server)

\- pyright:
[https://github.com/microsoft/pyright](https://github.com/microsoft/pyright)

\- pyre: [https://pyre-check.org/](https://pyre-check.org/)

\- and of course mypy: [http://mypy-lang.org/](http://mypy-lang.org/)

I don't think any of them qualify, but they may all have little pieces.

Also, if you need to analyze Python syntax, baron will help:
[https://pypi.org/project/baron/](https://pypi.org/project/baron/)

Good luck.

~~~
carapace
Great list! There's also something called PySonar but you have to dig around
for it.

------
Epskampie
I think I’ve seen several of these now for python, seems very useful.

I hope a good one will be made soon for javascript/typescript.

Or maybe it’s needed less there because of typescripts type interference?

~~~
smt88
You’re correct that TS doesn’t need it due to its excellent type inference

------
anentropic
I will definitely check this out!

Very similar is
[https://google.github.io/pytype/](https://google.github.io/pytype/) which
also infers and adds annotations, as well as providing a type checker which in
some ways works better than mypy (recursive types!)

------
garrettgrimsley
Previous discussion:
[https://news.ycombinator.com/item?id=15982390](https://news.ycombinator.com/item?id=15982390)

------
FpUser
Not Python exactly but I have these situation. I am writing business server in
C++ that exposes JSON based RPC API and Javascript client library to access
said API.

I have no idea where is that claim about high productivity of these free form
languages came from. In C++ in addition to the nice intellisense compiler
checks everything before sending program to debug. So I do not need to do
manual testing during runtime to discover typo in my code.

In javascript I can write literally any crap and the system lets it go.
Intellisense sucks big time as well. As a result of this and usual typos I
have to literally go and do a lot of clicking to see if this part blows up at
runtime.

So all in all I'd say productivity in C++ is way better. And C++ is not a
stellar example of easy language. Actually it is easy for me. Not because I am
super-duper programmer but your basic coding with the help of standard library
is a piece of cake. I do not really need to be an architecture astronaut and
dive into any esoteric stuff. Simply not needed

~~~
gcthomas
To answer your question, Python is several times more expressive than C++
given that is is a higher level language, and since fewer lines are needed for
a given program it is likely to be quicker to write.

To quote Martelli from Google talking about how the Youtube startup outran
Google Video's might so much that they had to buy them:

"Eventually we bought that little start up and we found how 20 developers ran
circles around our hundreds of great developers. The solution was simple!
Those 20 guys were using Python. We were using C++. So, that was YouTube and
still is." [1]

Google took months to copy new YouTube features, while YouTube could catch up
in a week after Google innovated.

[1] Google Books, search term 'python interviews google vs youtube'

~~~
FpUser
1) A was talking about JavaScript

2) I do use Python but mostly for administrative/deployment/similar tasks as a
scripting language. I see no proof that Python is "several times more
expressive". I would really appreciate if you could kindly point me to a real
study that shows exactly how it is more expressive and on what in particular
the time is saved (you can of course omit the examples where Python is used as
a glue language to stitch together few math libraries written in C/++).

I do have my own experience. Of course it is statistically meaningless. My
friend and I have implemented simple GUI desktop app (custom video player with
some features) as a bet. My buddy did it in Python and I did it in Delphi. I
won: 1 hour vs 4.

~~~
gcthomas
"An empirical comparison of c, c++, java, perl, python, rexx and tcl"

Lutz Prechelt

IEEE Computer 33 (10), 23-29, 2000

80 implementations of the same set of requirements, created by 74 different
programmers in various languages, are compared for several properties, such as
run time, memory consumption, source text length, comment density, program
structure, reliability, and the amount of effort required for writing them.
The results indicate that, for the given programming problem,“scripting
languages”(Perl, Python, Rexx, Tcl) are more productive than conventional
languages. In terms of run time and memory consumption, they often turn out
better than Java and not much worse than C or C++. In general, the differences
between languages tend to be smaller than the typical differences due to
different programmers within the same language.

~~~
FpUser
Did some reading. The first thing that puts me on alert about the result is
this:

" Most programmers in the script group used the associative arrays provided by
their language and stored the dictionary words to be retrieved by their number
encodings"

For C++/non-scripting they either used plain arrays or custom build tree in
one case. So they had to write lots of code.

Sorry but there are associative arrays in C++ standard library and search and
this and that. Building the program they've specified would be a no brainer in
modern C++. This article is irrelevant for current situation.

------
plafl
Awesome. I will try this next Monday on a code base at work, I hope it will
improve readability. I admit I'm a little skeptical about the adoption of
optional typing if it's not going to affect performance but maybe this will
change my mind.

------
mkchoi212
Haven’t been involved in the Python community for awhile but isn’t already a
thing? Really cool project but thought I saw something like this already
existed. If I’m right, is there anything that stands this apart from its
counterparts?

------
Browun
What's the benefit of this over simply adding the type annotations directly? I
guess this is mostly for those unwilling to understand types? Especially given
the admitted limitations of inferring types, such as the add exmaple
discussed; this seems to be fixing an anti-pattern problem. As this those who
would build a project in Python that would largely benefit from these
annotations, would be most suited to just spend the couple of hours needed to
truly apply it themselves.

~~~
resoluteteeth
Have you actually spent time adding type annotations to existing python code?
In my experience it's a huge pain compared to other languages. Documentation
is sloppy about types because people aren't used to worrying about them, so
even looking at the code it's really hard to even determine the actual types
of things without just running it and poking around.

~~~
Browun
Not sure why the initial tone of your response is quite so dismissive. But I
do work with Python on a daily basis, even though this shouldn't be the
deciding factor on the validity of any point. Discuss the point, not the
individual, if it's so easy to disprove. It seems that you're talking about
poorly documented code, not how type checks effect this. Python code should
have at least docstrings for types, or a scrawl with pen and paper describing
this. If not, this is a failing of the project, and it's codebase. Not
something you should rely on an outside tool to fix.

------
lmeyerov
Is there any level of growing community consensus on a types/contracts-for-
python effort?

------
asplake
Nice! I see some Django-related FAQs. Anyone used this with Flask?

~~~
Bnshsysjab
It should be relatively straight forward, it deduces typing based on your unit
tests and CI.

------
rajbiswas125
Would python finally become statically typed?

~~~
BiteCode_dev
No. It's been explicitly stated that Python will:

\- never become statically typed

\- never make the type hints mandatory

\- never enforce the type hints at run time

Python is jokingly said to be "the second best language for most things". To
achieve this, it has to be able to be decent for many different purposes such
as setuping machine learning models, scripting SIG system, doing test
automation, powering a web site, provisioning linux servers, scrapping web
page, batch renaming files and teaching code, analyzing numbers from a hdf5
file, being the client to a database/ftp/ssh/imap system.

It means it can't just be purely functional/OOP/imperative, be must borrow
from each paradigm. Be statically typed or not, but gives features from both.
Etc.

Because you don't want type hints when you are in jupyter or scripting your
linux box. But you may want it when your Saas reach 3 millions lines.

~~~
pansa2
> It's been explicitly stated that Python will never make the type hints
> mandatory

Type hints are already mandatory if you want to use data classes. This is
unfortunate - the two features really should be orthogonal.

At least when Guido was still BDFL, there was little resistance to type hints
encroaching on unrelated areas of the language, and hence becoming less-and-
less optional.

