
Pyre: Fast Type Checking for Python - jimarcey
https://www.facebook.com/notes/protect-the-graph/pyre-fast-type-checking-for-python/2048520695388071/
======
seanwilson
It's interesting how static type systems are slowly gaining more adoption now
by being bolted on to popular dynamic languages. It feels like a weird
approach compared to using a language that was designed from the ground up to
have a strong static type system but it's practical in terms of easing people
into it.

~~~
ericmoritz
Java's verbosity made us all hate type systems in the early 2000s so many of
us migrated to dynamic languages such as Python, Ruby in the mid 2000s that
allowed us to work fast and loose and get things done.

After about 10 years of coding in a fit of passion we ended up with huge
monolithic projects written in dynamic languages that where extremely brittle.

Fortunately languages with type inference (Rust, Golang, OCaml, Scala, etc)
started becoming the answer to our problems. (We also collectively decided
that Microservivces were another solution to our woes though that cargo cult
is being questioned).

So we have a decade of code and packages written in Python and JavaScript that
work well for our use cases (Data Science, MVP web apps/services, Database
integration, etc) that is hard to give up. Often because alternatives aren't
available yet in the statically typed languages (Hurry up Rust!).

There is often a lot of friction to get new languages introduced. I love Rust,
but I don't think I can introduce it into our Golang/NodeJS/Javascript
environment anytime soon.

~~~
tootie
Verbosity is usually the worst argument against a language. Your coding
efficiency is not limited by how fast you can type. I've been using Kotlin
recently which is basically just Terse Java and it's very nice but hasn't
turned my world upside down.

~~~
kccqzy
Verbosity absolutely hurts comprehension of code. It's easy to hide hugs in
code that seems to be just boilerplate. It also means that given a fixed
screen estate you can less of the actual logic of the code at a time.

~~~
ethbro
Absolutely this.

For whomever tells me verbosity isn't a limitation to a language: find me the
single incorrect statement in a 100 line function vs a 10 line function.

And no cop outs with "I use {bolt-on sub-language that makes parent language
more concise}" (that's not a mainstream language then) or "Well, you can just
ignore all the boilerplate" (bugs crop up anywhere programmers are involved).

Or give me an ad absurdum concise counterexample with APL. :P

Ultimately language verbosity is mapped directly to proper abstraction choice.
In that the language is attempting to populate the full set of information it
needs, and can either make sane assumptions or ask you at every turn.

~~~
dnomad
The fact that even the pythonistas are now adopting types suggests that
verbosity is much less of a concern than a bunch of spaghetti code that cannot
be tested, understood, or refactored. You have to squint really, really hard
to think that the people who chose type-less languages over Java ten years ago
actually made the right choice. Personally, when diving into codebase its
"verbosity" has _never_ been an actual issue. Nor has lack of "expressive
power." Of much greater concern is how well modularized it is, how well the
modules are encapsulated, and how well the _intentions_ of the original
authors were captured. Here verbosity and types in particular have been
absolutely invaluable. I suspect in the end this is why serious development at
scale (involving many programmers over decades) will never occur in "highly
expressive" languages like lisp and to a lesser extent, ruby etc. It is simply
not feasible.

~~~
nemothekid
As I dive deeper and deeper into this thread, it looks like people are
confusing "verbosity" with "it-has-a-type-system".

Java (5,6) wasn't verbose just because of types. Java was verbose because the
language, and everything surrounding it was verbose. It was difficult to read
Java at times because the language had been gunked up with
AbstractFactorySingletonBeans. FizzBuzz Enterprise Edition is a joke that is
only funny and simultaneously dreadful in the Java world. However, despite
being relatively more complex, Rust is far less verbose than Java- even though
Rust is more powerful with regards to types. "Hello World" in rust is 3 lines
with just 3 keywords. The Java version has _12_ keywords.

Engineers ten years ago weren't choosing Ruby/Python over Java because of
static typing. They didn't choose Java because it was relative nightmare to
read and write.

~~~
pjmlp
10 years ago I was writing Java and still am today, alongside other languages.

I will never chose Python/Ruby for anything else other than portable shell
scripts.

~~~
ageofwant
15 years ago I wrote Python code for a living. Then about 9 years of Java. The
last four years was exclusively Python. I'm never going back to Java, it has
nothing I want.

~~~
ivanhjc
What's your job while using Python?

------
cx1000
Hypothesis 1: All successful dynamically-typed programs eventually grow large
enough to get rewritten or retrofitted with static types.

Hypothesis 2: All successful statically-typed languages eventually grow large
enough to have a dynamically typed scripting language embedded in them.

[https://twitter.com/munificentbob/status/988555364252631040](https://twitter.com/munificentbob/status/988555364252631040)

~~~
dudul
While I see a lot of examples of 1), I can't think of one for 2). Which
successful statically-typed language has that?

~~~
munificent
For 2, I should have said "programs written in statically-typed languages".
Oops.

Examples are most text editors: emacs (elisp), Sublime Text (Python), Vim
(VimScript), Atom (JavaScript). Many games and game engines: World of WarCraft
(Lua), Unreal (UnrealScript), SCUMM, etc.

~~~
weberc2
I'm guessing you meant these hypotheses to seem paradoxical (i.e., dynamic
code bases are rewritten in static languages to improve maintainability;
static code bases are rewritten in dynamic languages to improve
maintainability), but I don't think they are.

Dynamic codebases are rewritten in static languages to improve maintainability
and code quality; programs written in static languages include an interpreter
as a feature that supports user-defined programs, e.g., a browser's JS engine
or emac's text editor and also for specialty domains where code quality is
less important than developer velocity and the static language of choice is
unnecessarily painful (games).

Assuming I didn't misrepresent your thesis, does this seem more or less
accurate to you?

~~~
munificent
No, I actually didn't intend them to be paradoxical.

My feeling is that statically-typed languages and dynamically-typed languages
are each better suited for certain kinds of problems. The former gives you
better performance, long-term maintainability, and scales to larger programs.
The latter gives you a faster iteration loop, is easier to learn, and is
easier to dynamically load.

I think what happens is that any sufficiently large program covers so many
different requirements that eventually different parts of the program are best
implemented in different styles of language.

If you start statically-typed, you eventually get bogged down by the slow
compile-reload cycle, need to dynamically load user-defined code, or what to
express parts of the program in something higher level or more declarative. So
you end up embedding a scripting or configuration language.

If you start dynamically-typed, eventually your program grows to the point
that you either can't maintain it or it isn't fast enough, so you end up
trying to bolt a type system onto your existing code or rewriting parts of it
in a statically-typed language.

I think the costs for the latter are usually higher than the costs for the
former, so I tend to lean towards starting statically-typed, but that's also
because I'm comfortable using types.

~~~
weberc2
Ah, thanks for clearing that up. I forgot compilation can take a while. I used
to write C++, but the only compiled language I've worked seriously with in the
last several years has been Go, which tends to compile in about the same time
it takes a Python program to load its imports.

------
okl
I use mypy[0] for PEP-484 type checking on a regular basis in large projects.
PyCharm[1] supports PEP-484 type checking as well and displays errors in the
editor.

\--

[0] - [http://mypy-lang.org/](http://mypy-lang.org/)

[1] - [https://www.jetbrains.com/pycharm/](https://www.jetbrains.com/pycharm/)

~~~
gipp
Mypy is the standard, but too slow to integrate into editors (more appropriate
for CI). PyCharm built its own implementation for this reason, but of course
it's proprietary. Pyre's trying to get typecheck integration into other
editors.

~~~
klibertp
Why do you think it's too slow? I have it integrated with Emacs' flymake and
it works pretty well. It takes less than a second to run mypy and display its
results (with red underline or whatever else you have configured). From my
experience, Visual Studio with F# takes similar time to type-check and show
errors.

~~~
zokier
A second is an eternity for interactive use.

~~~
m45t3r
Well, I am start to writing some Typescript with tslint configured on save,
and it takes way more than 1 second for a small toy project.

Even just building this project with Typescript compiler takes more than 1
second. And I don't think it is that bad because at least the process is
async.

~~~
elbear
Interesting. I write TypeScript in PyCharm and I get feedback as soon as I
write (PyCharm performs save automatically). I don't know how they implemented
it that it's so fast.

~~~
komon
Well, PyCharm is already doing a lot of parsing for syntax highlighting and
autocompletion and other goodies. They're checker implementation probably just
takes the AST PyCharm already has available to it, which saves the round-trip
of saving to a file and having an outside checker open and re-parse the file.

------
luckycharms810
What’s interesting about this announcement is that they not only announced a
type checking tool, they are also open sourcing a tool that will apply a patch
and annotate your code with types for you. I tried a demo of this at the
Instagram booth at pycon yesterday. They basically had a package that would
run your tests for you, and using the coverage that you created, it could
infer the types while executing your code. Now if the point of type
annotations is purely to check for bugs that are avoided in statically typed
languages it seems like you should be able to just combine the two tools and
catch type based bugs without ever applying the annotation.

I think the type checking community also has quite a ways to go when it comes
to asynchronous code. It becomes quite worthless to check that a future is
being returned by a function, but it could be more helpful to know what that
future will eventually yield.

~~~
kasbah
Surely `await f()` should be a type error if `f` doesn't return a future and
checking for that seems useful. I am not up to speed on Python's types but in
most type systems you can do something like `f : Future<Int>` which _will_
tell you what the future will eventually yield an `Int`.

------
nebgnahz
So, there is a trend to build static type checker for popular managed dynamic
languages?

Facebook also built Flow, a type checker for Javascript [1].

[1] [https://flow.org/](https://flow.org/)

~~~
GordonS
It does beg the question: why not use a statically typed language in the first
place?

~~~
owaislone
I think languages like Go are changing that. Most of the statically types
languages have been very verbose and often more lower level than people like.
If you are building a new web service, python, ruby or JS are very attractive
as they help to get something out of the door very quickly. I think Go hits
the right spot here between verbosity and safety/expresivness, and a lot of
new startups are choosing Go for things they would have built in Python or
Node. I think this will only improve as more dynamic languages start adopting
static typing and most static languages start adopting things like type
inference, etc.

~~~
Captain_Usher
>I think Go hits the right spot

You make an excellent point here that I don't see articulated very often. The
Landscape of Popular Languages, let's say C/C++/Java/Python/Ruby/JavaScript,
has a big gap in the middle. You have good choices between:

1\. lower level "systems" oriented languages with static types, usually
compiled, like C++. You get lots of flexibility and direct access to
primitives. Static types help wrangle big codebases. Generally suited to large
projects.

2\. higher level "scripting" oriented languages with dynamic types, usually
interpreted, like Python. Writing code for most tasks is easier. You give up
some stuff you'd want for projects like operating systems or databases. Most
projects aren't operating systems or databases, so that's usually a good
tradeoff. Generally suited to small projects.

The problem is that lots of projects are medium-ish. You set out to build your
web service backend or whatever, it would be a pain in the ass to write in
C++, so you use Python. Getting it working is quick and easy. A few months
later it's big, complex piece of software and working on it in Python is a
pain in the ass. You can't win. What you really wanted was a language that's
"easy to write" like Python, but with static or optional types, maybe better
thread handling, and at this point the interpreter isn't doing much for you so
it might as well be compiled. There are tons of cases where you just want a
"better C" or "Python but faster and with static types", and for the longest
time the Landscape of Popular Languages just had a giant hole there.

We needed that space filled and Go delivered. I'm usually very critical of Go,
but I can't hate on it for being the wrong kind of language. It's definitely
the right kind of language for these "goldilocks" problems that aren't too
high or too low level, too big or too small. Part of being a good programmer
is understanding that languages are tools, and you need to pick one that fits
your problem. Go deserves all the success and praise it's gotten for being a
language that fits actual problems.

------
neuland
It's cool to see another type checker! I haven't had any big issues with MyPy,
but competition is good in a healthy ecosystem.

The language server / editor integrations are an interesting goal and that
seems to be why they have the watchman stuff in there.

I was initially kinda put off by that, as tools that watch for file events
never end up working for me because I save like every 10 seconds.

~~~
phooji
You can run Pyre without using watchman if your editor-of-choice supports LSP
-- the two modes are basically complementary. You can also run `pyre check` in
non-incremental mode, though that may be slower depending on the size of your
codebase.

~~~
neuland
So you're saying the LSP portion checks the file(s) you're currently editing,
whereas the watchman (also incremental) check or the non-incremental check do
the whole project?

Edit: for the active file / LSP part, I mean it shows errors mainly for the
active file.

~~~
sinancepel
Exactly - the LSP portion of pyre works for files you have open in an editor,
but might miss changes due to a rebase or files you edit on the terminal. The
watchman integration is there to make sure that pyre's aware of changes
outside your editor.

Edit: pyre will show type errors for all files in your repository, not just
the ones you have open.

~~~
neuland
Ah, that's nice. So you can change the type of a function in one file that you
are editing, and pyre will show you all the other places that are now using
the wrong types.

------
jedberg
The Python stuff is cool, but I was actually more excited about asciinema[0],
the tool they used to make the demo video.

It actually makes ascii move around so that someone can pause the "video" and
copy/paste out of it! Thats so cool!

[0] [https://asciinema.org](https://asciinema.org)

~~~
kevin_thibedeau
Asciinema has the fatal flaw that it is dependent on their server. When they
go under so do your recordings. There are other options out there that can
handle playback of traditional console recordings without such dependencies.

~~~
Karunamon
It is fairly easy to set up your own: [https://github.com/asciinema/asciinema-
server](https://github.com/asciinema/asciinema-server)

------
fithisux
Python is a very good language for academic use. It is a more featureful FOSS
system that can be used for RAD or matlab like purposes. Lack of types is not
a serious problem for small codebases. But when the code base passes the
magical 10000 line spot, type problems start to become serious. I hate the
annotations about types in comments it is not maintenable.

Either you create a codebase strictly modularized respecting the lack of types
and the 10000LOC speed limit or you change language. Golang is not fancy but
it is really pragmatical and could appeal to the dynamic language crowd.

The other choices are Java/D/Scala. Or one can use Python as a glue language
(superpowered C written modules used by Python). This is the problem/solution
with Lisp too. If you go dynamic, you should be very careful, but there are
gains. Don't forget to write tests unless you intend for a Matlab style
experience.

~~~
stevesimmons
Python scales to large code bases too.

I work in a decade-old Python codebase that is now up to 30m LOC. Our 2000+
developers are doing 15k commits a week, with continuous deployment.

(I gave a talk on this at PyData London two weeks ago)

~~~
fithisux
My personal experience shows that you need many separate codebases to achieve
30m LOC, in other words many small projects of the 10.000 LOC code limit.

Do you work this way?

~~~
stevesimmons
This is the main trading and risk management platform for a bank. A central
team of around 150 people build the core platform libraries and underlying
infrastructure. Then business-aligned teams build applications on top. The
code is in one huge mono-repo.

------
mehrdadn
This doesn't work on Windows? I'm getting an error installing it:

    
    
      > python --version
      Python 3.6.1
      
      > python -m pip install pyre-check
      Collecting pyre-check
        Could not find a version that satisfies the requirement pyre-check (from versions: )
      No matching distribution found for pyre-check

~~~
masklinn
Looking at the published package, they're binary wheels and only published for
linux/AMD64 and OSX 10.13/AMD64. I guess it's manual installation for
everybody else.

~~~
mehrdadn
Wow. Do you know how they even build this thing? The instructions I see just
keep saying pip install everywhere. I don't see any
setup.py/configure/Makefile/etc.

~~~
gknoy
The documentation includes info on building from source:

[https://pyre-check.org/docs/installation.html#building-
from-...](https://pyre-check.org/docs/installation.html#building-from-source)

~~~
mehrdadn
Ahh thanks! I was just looking at the repo.

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

Github: [https://github.com/facebook/pyre-
check](https://github.com/facebook/pyre-check)

~~~
danso
OT: I thought the docs for pyre-check.org looked really nice. Didn't look like
a Jekyll or Sphinx template. Looked at the source code and it's another FB
library, Docusaurus, which uses React and Markdown:
[https://docusaurus.io/](https://docusaurus.io/)

Had been briefly discussed a few months ago on HN [0] but I guess I missed it.
Always looking for some variety in static site/docs deployment!

[0]
[https://news.ycombinator.com/item?id=15924779](https://news.ycombinator.com/item?id=15924779)

------
ben509
It should be easy enough to put together a flycheck plugin for emacs users.
I'll post a comment here when I'm done if you're interested.

~~~
phooji
Please send us a pull request if this is something you'd like this to live in
the pyre-check repo!

------
m0meni
I'm curious what the proponents of dynamic typing over static typing think
about the recent push towards adding type systems to the two biggest dynamic
languages out there: Python and JS.

~~~
brightball
IMO it’s that people coming from static languages to dynamic languages want
them.

I honestly can’t think of anybody in my career who’s been comfortable with
dynamic languages that had a desire to move to static. It’s such an impediment
to the entire programming style that it doesn’t naturally happen.

On the flip side, I know plenty of static typing people who don’t seem to
think they can function without it.

No matter what your preferred language, Python and JavaScript are almost
unavoidable and because of that I think you see a lot of stuff like this
brought to the table to help make people more comfortable.

Python for sysadmin, math, ML, etc. Javascript for browser.

You see a lot of the same thing in the Elixir community with its gradual type
system. I can’t tell you how many times I’ve seen the discussion from people
who want it to be statically typed, but neglect that all of the guarantees
from it go out the window with distributed nodes.

~~~
RussianCow
> I honestly can’t think of anybody in my career who’s been comfortable with
> dynamic languages that had a desire to move to static. It’s such an
> impediment to the entire programming style that it doesn’t naturally happen.

Really? Anecdotally, I have the exact opposite experience: I know many devs
(myself included) who had always used dynamically typed languages but got
"hooked" on static typing after trying it in a decent language (Swift in my
case), but I can't name a single person who went the other way.

In my experience, if you use a modern statically typed language with a solid
type system, after the initial learning curve, the type system stops being an
impediment to probably 95% of the code you write. In return, you get some
really nice guarantees about your code, and what would be large and tedious
refactors in a dynamically typed language now become a breeze. And if you bolt
static typing onto a dynamically typed language, you get the best of both
worlds: safety guarantees by default, and the full expressiveness of the
underlying language when you need it.

Personally, I'm excited for these tools because I write code in dynamically
typed languages every day, but I strongly value the benefits of static typing.
This way, I can have my cake and eat it, too.

~~~
brightball
I really think a lot of it depends on your stack. On the web application side,
I find static typing to be entirely an impediment - usually because the types
that I really care about are already defined at the database level.

Every statically typed language I've worked with on the web just ends up
forcing you to duplicate the same already defined structure in multiple
places, writing a ton of extra code that provides marginal benefit but creates
a major negative impact on productivity.

For many other areas, especially on phones, embedded devices or desktop
software static types will make a lot more sense.

I think languages where the primary focus is data exchange the benefits are
less pronounced. That's just my experience though.

~~~
RussianCow
But it's still incredibly beneficial to annotate the edges of your API. Not
only does that quickly catch mistakes where you break the API contract, but it
also serves as built-in documentation on the shape of the data you are
serving, especially if you are using a dynamic format like JSON. And that's
the beauty of having static types in a language like Python: you don't have to
annotate _everything_ , and can be selective about where you apply static
typing to get the most bang for your buck.

~~~
brightball
I can appreciate that. I like the add where helpful approach. It’s having to
do it everywhere that’s such a problem.

------
ericpts
I am particularly curious why they chose to start from scratch instead of
cooperating with Dropbox on mypy.

~~~
phooji
Good question [I am the 'Pieter' on that blog post]. There will be a talk at
PyCon that covers parts of this. It comes down to two reasons:

1) Performance. We needed something that would consistently work quickly on
Instagram's server codebase (currently at several million lines).

2) We are building deeper semantic static analysis tools on top of Pyre. We've
built some of these tools for Hack/PHP already, so following the Hack type
checker's architecture is the best way for us to achieve this.

~~~
Twirrim
> 1) Performance. We needed something that would consistently work quickly on
> Instagram's server codebase (currently at several million lines).

That's not really an answer to why you didn't work on mypy, at least to an
outsider to the decision making process. Are you saying that you discovered
it's just not possible to scale mypy (or at least not without extensive work /
more work than building your own solution?)

I can appreciate the choice in context of 2) :)

~~~
phooji
I think (2) is the overriding concern: we're getting really great results with
the static analysis tools we've built internally on top of the Hack type
checker. Building a similar tool on top of mypy would've required fairly
invasive changes; we decided to use the Hack type checker infra instead.

Full disclosure: I worked on the Hack type checker briefly, a long time ago :)

------
Rapzid
This is a great development for Python. The language services ecosystem was in
the ICU, but perhaps now it's just on life support. VS Code, my editor of
choice, supposedly has a pretty good python experience.. That was not my
experience; slow! Just pulling tensorflow into a project would introduce
serious save lag. Lag that's pretty much omnipresent to a lesser degree. Save
and wait for syntax error updating... And wait.. Pylnint and Jedi were just
not up to the task. A speedy language server is just what the doctor ordered.

Still, annotation/inference experience falls apart completely when interfacing
with libraries like SQL Alchemy or boto3. Supposedly writing custom plugins is
the way, but that never gets done! How will pyre handle stuff like this, or is
it just asking too much? Perhaps a combination of better tooling _and_ better
library authoring, eschewing the temptation of meta programming and dynanimo,
to play well with type hints will be necessary?

I'm excited for these new tools and will give it a play. However I honestly
hope I never have to work in a python-forward environment again.

------
galonk
Anyone know how this project's capabilities compare the the PEP-484 checking
built-in to IDEA/PyCharm? That implementation goes "above and beyond"
inferring types based on use when there's no explicit annotations. I'm
wondering if other projects are doing that kind of thing.

~~~
shannonzhu
We haven't yet released a type inference feature, but have been building and
using one internally. It helps by adding type annotations directly, based on
what the type checker is able to infer. We're hoping to release this feature
in the future.

Also, MonkeyType will allow you to add types to your Python based on types
inferred at runtime:
[https://github.com/Instagram/MonkeyType](https://github.com/Instagram/MonkeyType)

------
edward
They accepted my spelling correction pull request.
[https://github.com/facebook/pyre-
check/pull/3](https://github.com/facebook/pyre-check/pull/3)

~~~
airstrike
Next up is re-recording the video at [https://pyre-check.org/](https://pyre-
check.org/) so the coder uses vim more fluently.

------
leshow
I was under the impression that Ocaml was single threaded? How is it that they
have type checker that runs in parallel?

~~~
sinancepel
You can have multi-threaded OCaml (our server actually has two threads), but
only one can run at a time currently. We solve this problem by having a multi-
process architecture where workers only communicate through a lock-free hash
table in shared memory.

~~~
leshow
Is it fair to say that it runs in parallel if only one thread may run at a
time? Isn't that concurrent, but not parallel?

~~~
platinumrad
Both responses to your original question mention that multiple processes are
run.

------
elbear
I'm glad to see more mind-share for static type checking in the Python
community. At the moment, types aren't as popular in the Python world as they
are in the JavaScript world where you can find TypeScript type definitions for
most libraries.

I hope adding types to your library becomes the norm in Python as well,
because as it stands, very few Python libraries have types defined. This means
you can only have type guarantees in the code you write and not in that of
your dependencies.

------
cup-of-tea
If you're going to go to all the effort of declaring types, why not use a
language that can take advantage of that information to get faster and more
efficient code?

~~~
always_good
Because you already have Python code. Or because throwing out the baby with
the bathwater isn't a smart business decision.

------
kodablah
Somewhat off-topic: Does anyone else feel the need to avoid products purely
because of their maker regardless of quality? I like some Nestle products but
avoid them because of their maker. I am also avoiding GraalVM for the same
reasons. Some things we can't avoid of course (especially those with momentum
or without equal), but if I can avoid things built by companies I don't like,
I will (digitally and in meatspace). Am I unreasonable?

~~~
dijit
Probably, but there is a lot to be said for having a moral sense.

I will never use Oracle products or allow them to bleed into my infrastructure
for any reason for example.

It's possible that this has saved my company a lot of money, it's also
possible that it was completely unjustified, but given the trend of the
company in question- I believe it was a positive decision. Make choices, the
best you can in the moment, you can usually revisit them later.

------
pcx
Argh, would love to have one for Ruby too! I am a big fan of Flowtype,
definitely going to check out Pyre!

------
sjroot
Does this comply with the type hinting format outlined in Python 3's typing
module? [1]

[1] [https://docs.python.org/3/library/typing.html#module-
typing](https://docs.python.org/3/library/typing.html#module-typing)

~~~
sinancepel
Yes! Pyre adopts types from the typing module, and relies on typeshed[1] to
infer types for standard library functions.

[1]: [https://github.com/python/typeshed](https://github.com/python/typeshed)

------
mlevental
what i don't understand about stuff like this (and honestly typescript as
well) is if there aren't definitions for type schemas then this doesn't work
right? like none of these tools will introspect or something and figure out
which types i really mean without me annotating with some kind of crazy
sum/tuple type definition (e.g. foo() -> Object{a:b,c:d} or whatever it is in
typescript). maybe i'm wrong and there's something different here?

~~~
avbor
Instagram actually has a program for stubbing existing code called MonkeyType.
It requires running your code to collect the data, and then after your run
finishes you can then apply the new inferred types to your program.

~~~
mlevental
so like can i throw my entire django app at this thing and have it spit out
types for me? probably not right?

~~~
mhlakhani
That's actually correct - it will spit out types it can infer.
[https://github.com/Instagram/MonkeyType](https://github.com/Instagram/MonkeyType)

~~~
carapace
(Oh daaaamn that's cool!)

------
uryga
I'd be happy to be corrected on this, but the documentation seems a bit...
bare? I've used mypy, and I'm interested in types more complicated than `foo()
-> int`. I'd like to see how pyre handles generic stuff, unions etc... Maybe
that's all rolled into "we support PEP X", but it'd be nice to see some
examples.

(I might have somehow missed the full docs - in that case, if anyone has a
link, I'd be grateful.)

~~~
sinancepel
If you're interested in the details of how pyre handles generics, unions,
etc., you can take a look at the end-to-end typechecking tests, which provide
lots of examples: [https://github.com/facebook/pyre-
check/blob/master/analysis/...](https://github.com/facebook/pyre-
check/blob/master/analysis/test/analysisTypeCheckTest.ml)

~~~
uryga
Thanks! I'll dig into it later, as I've been looking for a tool like his, and
it so happens that the details are interesting to me :) (I built my own
namedtuple-style library for sum types, go figure). It didn't seem like the
easiest reading though - that could make some potential users bounce... Are
you working on docs that expose these features in a friendlier way?

edit: Also, was I correct in that it's basically "The stuff that's specified
in the PEP and works in mypy should work"?

------
bhahn
On mobile web, pressing back from the note sends me to Facebook's homepage,
not to hn. Anyone else notice this? This is on top of the pop-up modal
prodding me to add a shortcut to Facebook on my home screen. These are the
kind of annoyances and "tactics" that make me dislike Facebook and want to
stop using them.

Aside from that, pyre looks like a super useful tool. Hopefully it has fewer
rough edges than mypy.

~~~
vjeux
This is a bug, could you send me the details at vjeux@fb.com? It goes back to
HN for me.

------
augbog
I'll be honest -- we've been using Flow for JavaScript on our team for a while
and we can't get over a lot of the problems we run into with Flow. We have
been considering moving to Typescript. I can't really see how adding a static
type checker to Python will be any better.

I know it's probably better than nothing but if the same problems carry
through, it'll be a pain.

~~~
weberc2
Python’s type checking story is pretty painful right now, partly because the
typing library has a lot of confusing corners, MyPy (the reference type
checker implementation) is pretty buggy, the rules are limiting (no support
for interfaces/protocols and no recursive types), and magical code like
SQLAlchemy simply can’t be type-stubbed.

These are all tractable problems, so I don’t see a theoretical problem;
however without more info on your flow issues I can’t make a good comparison.

~~~
agravier
Generally true but MyPy has some support for protocols
[http://mypy.readthedocs.io/en/latest/class_basics.html#proto...](http://mypy.readthedocs.io/en/latest/class_basics.html#protocols-
and-structural-subtyping)

~~~
weberc2
Whoa, I didn’t realize structural subtyping had landed already. Thanks for
sharing!

------
newscracker
I'm curious. Why the name "pyre" and how did it get that name? I get the "py"
at the beginning to refer to python. What dead things are being symbolically
(or otherwise) being burned here?

Edit: I did skim through the comments here and also skimmed through the
official site and the GitHub repo. I didn't find anything about this name.

~~~
jwilk
"re" of course stands for regular expression... Oh wait, no.

The person who came up with this name didn't think it through.

~~~
newscracker
Regular expressions is what I thought when I just saw the name, but it didn't
make sense in this context.

------
miggyrozay
Hoping this gets us closer to pycharm-like type checking for
jupyterlab/notebooks. Or does that already exist?

~~~
mdaniel
[https://www.jetbrains.com/help/pycharm/ipython-notebook-
supp...](https://www.jetbrains.com/help/pycharm/ipython-notebook-support.html)

I've tried it back when we were using PySpark and it did what I expected, but
I am not the heaviest consumer of Jupyter notebooks to be able to say if it's
80/20 or 100% of what one would expect

------
hayd
Has anyone tried installing this? I get:

    
    
        $ pip install pyre-check
        Collecting pyre-check
          Could not find a version that satisfies the requirement pyre-check (from versions: )
        No matching distribution found for pyre-check
    

Just me? (I am on python 3.6 and pip(3).)

~~~
fermigier
Me too. I guess they provide binaries only for some platforms, and yours (and
mine) is not supported.

I tried to build from source but got another error after some time:

    
    
        File "ast/astStatement.ml", line 289, characters 41-74:
        Error: Unbound module Recognized
    

(NB: testing on Mac OS 10.10).

~~~
tuvistavie
Changing `INCLUDES = . parser ....` to `INCLUDES = . external parser ...` in
the Makefile fixed compilation for me.

------
thrawaylost112
Lately, facebook has lots of NIH.

------
tjpnz
Why would I want to use this over MyPy which has this problem largely solved?

~~~
phooji
Pyre is faster in some circumstances.

With that said, the real answer is 'it depends', and it may well be the case
that mypy serves your needs better.

------
devy
PEP-484 Type Hints are for Python 3.5+, sorry if you are running on Python 2.x
like majority of the Google python codebase does.

Update: for the downvoters, the PEP listed the python version for 3.5 here
[https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/).
Yes it does have a python 2.7 section but after Python 2.7 is discontinued
pretty sure Python core team won't support type hints on 2.x. On top of that,
not to mention the fact the type hint suggested on 2.x (as a comment) is
different from the official 3.x syntax.

~~~
eesmith
That PEP has a section titled "Suggested syntax for Python 2.7 and straddling
code", [https://www.python.org/dev/peps/pep-0484/#suggested-
syntax-f...](https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-
python-2-7-and-straddling-code)

> Some tools may want to support type annotations in code that must be
> compatible with Python 2.7. For this purpose this PEP has a suggested (but
> not mandatory) extension where function annotations are placed in a # type:
> comment.

mypy supports those annotations for Python 2 code. Quoting
[http://mypy.readthedocs.io/en/latest/faq.html#how-do-i-
type-...](http://mypy.readthedocs.io/en/latest/faq.html#how-do-i-type-check-
my-python-2-code) :

> How do I type check my Python 2 code?

> You can use a comment-based function annotation syntax and use the --py2
> command-line option to type check your Python 2 code. You’ll also need to
> install typing for Python 2 via pip install typing.

~~~
epage
I fully endorse this. We've been using mypy on our Python2/Python3 project
successfully. it is helpful for the type checking but I'm most interested in
giving good data to IDEs for code completion.

------
Bromskloss
Is there any chance of using this in conjunction with Coconut [0]?

[0] [http://coconut-lang.org/](http://coconut-lang.org/)

~~~
ambivalence
No.

Supporting an entire new AST and type system (pattern matching) is a large
investment. It can be made if there's enough of a userbase out there to
justify it. That doesn't seem to be the case. Not yet at least.

------
lostmsu
I use PTVS for the same purpose. (Python Tools for Visual Studio) They do
quite a bit of type inferring as well.

It is also open source.

------
FnuGk
How is this different from the build in optional types in python 3?

------
neves
Has anyone integrated it with Visual Studio Code?

------
pspeter3
Has anyone tried adding this to Bazel as a test?

~~~
ambivalence
That shouldn't be hard to integrate. At Facebook we have it integrated with
Buck which is pretty similar to Bazel.

~~~
pspeter3
Awesome, thanks! Sometimes tools require a global context which makes it hard
to split work into packages

------
philipov
Can't read this; can we get a non-facebook link please?

~~~
seltzered_
Here: [https://github.com/zachlatta/pyre](https://github.com/zachlatta/pyre)
:)

~~~
kharms
>Pyre is a command-line interface for Tinder built at the 2015 Stupid Shit No
One Needs & Terrible Ideas Hackathon in San Francisco.

------
zeth___
Python has not types.

Let me repeat: Python has no types.

It has built in classes that used to be types 15 years ago, but no types. [0]

90% of the holy war between strongly and weakly typed in python would be
resolved if we just removed all references for types from Python, and renamed
TypeError to UnsupportedOperand.

Pep 484 [1] is about class hints, and this software builds on top of that.
That has it's place, but it's an ugly hack that should not become a main
feature of the language.

[0]
[https://www.python.org/download/releases/2.2/descrintro/#int...](https://www.python.org/download/releases/2.2/descrintro/#introduction)

[1] [https://www.python.org/dev/peps/pep-0484/#type-definition-
sy...](https://www.python.org/dev/peps/pep-0484/#type-definition-syntax)

