
Pyright: Static type checker for Python - JacobHenner
https://github.com/Microsoft/pyright
======
scrollaway
I'm excited; this looks better than Pyre. It being in Typescript is ironically
enough a pretty big deal.

I think they're clearly writing this for vscode, right? I hope they are at
least. Having spent the last decade and half writing Python code, I have
completely stopped enjoying writing Python code (even typed Python) because of
how _good_ TypeScript and the VSCode typescript experience is. It doesn't even
sort of compare.

At this point I just want pretty much the same thing that happened to JS to
happen to Python: For MS to make a Python superset with _good_ type hinting
(not the atrocious pep484 syntax) which compiles down to Python.

… and wasm. Which compiles down to Python and wasm.

~~~
joshuamorton
What's wrong with the pep 484 syntax in your view?

~~~
scrollaway
PEP484 and the current state of typings in Python:

\- Imports everywhere. Even basic types (list, dict, set) have to be imported

\- Basic types don't share the same casing as the actual types they represent
(Set vs set, Dict vs dict, List vs list)

\- Awful support for enums.

\- Syntax is generally ugly. Typescript got everything right; it's intuitive,
clear, and scales pretty well even for complex types. I'd be happy if they
just copied typescript syntax.

\- Types have a runtime impact.

~~~
sleavey
Agree. One way to fix it would be to allow you to define the typing in a
completely separate file. Right now you can define some of it in a separate
file but not all of it. I keep the horrendous typing syntax out of my code by
not using it.

~~~
Too
Typing in a separate file defeats almost all the benefits of typing. Being
able to read the code _without_ also having to open a second source, the
documentation. It's almost as bad as going back to stoneage c++ with
header/source split up in separate files.

Reading and writing types should be fast, agile, easy and effortless. Only way
to acheive that is having it as close the usage as possible

------
anurag
Microsoft, Facebook, and Google all have their own Python type checkers now.

* [https://github.com/google/pytype](https://github.com/google/pytype)

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

~~~
Rotareti
Don't forget the one from Dropbox:

* [https://github.com/python/mypy](https://github.com/python/mypy)

~~~
stonecharioteer
The one blessed by Guido, you mean.

------
akubera
I just installed it. It gives red squiggly lines under variables that haven't
been assigned (typos) and for incorrect methods on variables it can type-
deduce. This is without me adding any typing-hints to the script I'm working
on.

Only issue I see immediately is it does not use the default sys.path that the
vs-code-configured python interpreter uses, so it cannot resolve some of the
packages I'm using.

But overall, very nice.

------
StaticRedux
Microsoft, please make one for Ruby! C# vet and lover of VS and VS Code, now
working on a legacy Ruby/Rails code base and hating a new life of lifecycle
callbacks, fat controllers, fat models, magic methods, and un-upgradeable
gems. Ugh.

~~~
jrs95
Rails has so much metaprogramming that static typing isn't really going to get
you very far. Type checkers and linters won't know what the hell is going on.

~~~
syastrov
Django has quite a lot of "magic" as well. There is work being done on a mypy
plugin to support this magic in addition to type stubs. It is already quite
usable and supports type-checking many common patterns:
[https://github.com/mkurnikov/django-
stubs](https://github.com/mkurnikov/django-stubs)

See also mypy's recent blog post on plugins (which are also used for
supporting Python 3.7's dataclasses, which are quite dynamic as well):
[http://mypy-lang.blogspot.com/2019/03/extending-mypy-with-pl...](http://mypy-
lang.blogspot.com/2019/03/extending-mypy-with-plugins.html)

~~~
stefano
Django and django rest framework make such a heavy use of metaclasses that I
gave up on using mypy for a Python project. My code was littered with
annotations and stubs and it still wasn't catching obvious type errors, and I
had to fall back to use `Any` in way too many places. Couple that with the
horrible typing syntax and the fact that mypy was slow, kept crashing with
segfaults and often wouldn't even signal type errors on fully typed functions,
and the result was a lot of effort for almost no gain.

If I compare that experience to when I switched from JS to TypeScript, it's
like night and day. TypeScript is designed to work well with development tools
and already existing libraries, while Python's static types feels designed by
someone who never worked with static types while completely ignoring code
patterns used in existing libraries.

------
berti
> Pyright is written in TypeScript and runs within node. It does not require a
> Python environment or imported third-party packages to be installed.

I know which of those environments I would prefer... it's not node. It makes
total sense for VS Code though, so fair enough.

------
fineoldcannibal
As someone who has worked with Eric Traut (the primary author of this from
what I can see) in a previous life, I will say you can take this to the bank
any day of the week. One of the best developers out there

~~~
person_of_color
How does he decide what to work on?

------
staticassertion
Is mypy not open source? Why not collaborate? Mypy performance improvements
are something that would be welcomed.

~~~
pvg
It's the second item in the README - one of the goals is no dependency on
Python.

~~~
staticassertion
Ah, I just searched for "mypy" and saw the performance bit. Seems kind of odd,
I see the vscode justification but if you're running this, having a dependency
on Python seems like a low bar?

~~~
pvg
I imagine the biggest driver/customer here is VS Code and then it becomes
about adding such a dependence to VS Code which they probably don't want.

------
o10449366
I could see this being nice if you work within VSCode, have to juggle many
Python versions, and already have Node installed, but I've personally had no
issues with speed or configurability with mypy and pyenv. I think it's an
interesting project, but probably half-baked at this point.

------
grandinj
Is it just me or did no one else parse this as a joke project because pyrite
== fools gold?

~~~
jefurii
Project logo suggests they're aware of it.

------
externalreality
I think this is great! Static typing is such a blessing. This one looks very
high quality. Static typing helps me read code and helps the compiler do
static analysis. What's not to like?

~~~
z3t4
Unnecessary annotations, and compile step. No runtime guarantees. More work to
rewrite and iterate although tooling makes up for it. Easier to write bad code
due to less need to understand the interfaces. Harder to write any code
although that might be a feature.

~~~
externalreality
I don't know if any of that is true. The annotations actually help me to
understand the code. I actually find it easy to rewrite and iterate with type
annotations which are like machine checked comments. I think the purpose of
the tool is to make it harder to write "bad" code, unless you mean "bad" in
the aesthetic sense then I can't see how that is true either. In general I
find it easier to write code since its easier to keep track of what the data
looks like.

What do you mean by interfaces?

But then this is an argument that I don't have much time for and too much time
has been spent on it already. Lets just say that if there are many major
companies that felt the need to invest in a type system for a popular
languages that don't have one, then there might be something too it.

~~~
z3t4
With interfaces i mean the code you mingle with, like functions and methods.
When you are half forced to read, at least the function signature, and or the
manual, in order to understand and use it, it will lead to fewer bugs. The
better you understand something, the more people reading it, the less bugs.
And by-product you optimize for readability and comprehension. I think a major
reason why companies chose to invest in static typing is that so many
developers are used to it coming from Java and other languages. Not necessary
static typing itself, but the tooling that comes with it.

~~~
externalreality
A type system is not a replacement for understanding. Where ever did you get
that idea? The annotations help you to understand the code, they don't make it
so you don't have to understand it.

I'd say python is about as popular as Java and so I don't see companies
investing a bunch of money to make Java programmers more comfortable when they
could just hire an army of Python developers if they wanted to. I just think
they see value in the static analysis that types provide. Read about why
Facebook added types to PHP they don't mention your hypothesis.

I don't mind programming in languages with dynamic type systems. I find it
just as fun. But I do think its easier when there is a way to easily keep
track of the type of thing being operated on. I mean the data is what is
actually being operated on, the more I can tell about the data from reading
the code the better. The most difficult systems I have ever worked on were the
ones where unshaped globs of data were being shuffled around in hash tables
and heterogeneous sequences. I would always have to use the debugger to find
out what was going on at a given point. The code was dispatching on value and
type. It was rough.

~~~
z3t4
I think static typing is needed in a low, middle level programming language to
help the optimizer, and make sure values doesn't go out of bounds. Fanny
enough higher level languages like JavaScript (and probably python to, I don't
know Python) are _strictly typed_ eg. you can never go out of bound and get
overflow errors, have dangling pointers, etc. When you already have strict
typing, there's less need for static typing.

If the statically typed language is compiled to a dynamic language, you will
lose most of the performance gains too, for example Dart is almost like
JavaScript-with-static-typing, but it's twice as fast because the compiler can
actually make use of the static types.

I also think static typing bolted on to a dynamic higher level languages do
push you into an object oriented paradigm. And I think the language becomes
uglier with annotations. And it makes people lazy so they name things x, y, z
because the type annotation fills in the rest. But who cares about syntactic
preferences, code readability and naming things :) The real reason you use
static typing is to catch bugs ... But the best way to catch bugs is to
understand the code, and have many people read it. When I see less good
programmers the workflow goes something like this:

-I want to do foo ... autocomplete ... fooBaz, fooBar, fooFoo ... hmm, what can I do with foo ... autocomplete ... foo.bar sounds like what I need, it takes a baz, new Baz() ... damnit how do I get rid of this null exception ...

I did what you suggested and looked up why Facebook created Hack, from a
release post (1): "but still spend time looking up mundane method names in
documentation"

They don't have time to read and understand code. :P I sometime jokingly say
"the code is the documentation". Jokingly because I know that is unacceptable,
but I most of the time actually do mean it. :P

"We didn’t want to slow the PHP workflow, so we came up with a new approach to
reconcile instantaneous feedback with type safety."

They addressed one of the issues with a compile step, eg slower feedback loop.

1: [https://code.fb.com/developer-tools/hack-a-new-
programming-l...](https://code.fb.com/developer-tools/hack-a-new-programming-
language-for-hhvm/)

~~~
externalreality
> They don't have time to read and understand code.

Where does it say that. It actually says the opposite quite clearly if you
cared to post the whole quote and not just what supports what you would like
it to.

> They addressed one of the issues with a compile step, eg slower feedback
> loop.

Can you explain to me how faster feedback from static types that they, a
concept which the article reiterates again and again, leads to a slower
feedback loop. Clearly the article and many more like it say that the feedback
loop actually speeds up with static analysis since you don't have to run the
code to get the feedback.

I'm not sure if you actually want to objectively reason.

~~~
z3t4
It's not wise for me to continue the discussion if you are going to resort to
mudslinging. I can not simply explain something at the sandpit level,
especially not to someone in an highly emotional state.

[this part contains sarcasm] If you read between the lines in the article, and
I've read it in other Facebook articles too (between the lines), understanding
code is a problem for Facebook, it's against their principle of "go fast and
break things". Good that they are not into the self driving cars business :P
[/this part contains sarcasm]

Traditional web development is a bit different from traditional development
with long compile times. In PHP for example, the code is evaluated on the go,
for every request. Development goes like this: Make change in .php file,
(upload the file), reload the browser to see what happened. If you add a type-
checker between, before they see what happened, it will slow down the
development process. This is how static types and type checking slows down
development by adding a compilation step. Facebook claim they fixed it, but
it's still a concern that need to be addressed when adding static types to
other interpreted languages.

I do acknowledge that tooling allows you to see type errors directly in the
editor/IDE before you reload the browser. You can however get that without
static typing, via inference. (type annotation do make building such tool
easier). It's however likely that the bug would be discovered during the
manual or automatic testing anyway, so you have to evaluate if the added
complexity to dev-ops from changing the language to add static typing, and
adding a compilation step, is actually worth it.

~~~
spapas82
Actually the most common php workflow I've seen is: Edit php files directly in
production, save, refresh. If you see a blank page (php syntax error, returs
HTTP 500) start sweating and quickly check apache error.log. Repeat until
syntax error is fixed (and initial feature is implemented).

Or to rephrase an old proverb:

Real php developers do it on production only.

------
etatoby
Flame mode on.

Can anybody explain to me why people seem to prefer using unsafe and
interpreted/slow languages (Python, Ruby, Javascript... which is only fast now
because companies have invested millions on it) and then spend a ton of
resources writing "type checkers" for these inherently unsafe languages
(Typescript, Pyre, Pyright) Why don't they simply use languages that are
already safe and fast by design? (Rust, OCaml...)

~~~
namelosw
Rust is not fast by design.

OCaml is kind of but still not as fast as Ruby for me at least.

I spent a lot of time learning Haskell and Scala and I'm still learning. And
they never caught up with ruby on rails in terms of velocity for me.

One big thing is about the feedback loop. Typesafe so what? Type is type, it's
not either value or business invariant. I'm not convinced as long as you're
not writing proofs in dependent-type languages like Idris. So, I still prefer
REPL that I can sure about in no time, and watching tests every 0.1s after I
change the code.

One can say interpreted languages are optimized for developing because when
you change the code, it can be just run once -- there's no point of compiling
it because in the next second you'll be changing it.

And compiled languages are optimized for the runtime, because it's compiled
it's ready to be run many times.

Of course, there are JIT for interpreted languages and interpreted static-
typed languages, but Haskell REPL is still pretty slow compared to Slime. And
for Rails, you can actually touch anything runtime entity in the console.

~~~
ernst_klim
>it's not either value or business invariant. I'm not convinced as long as
you're not writing proofs in dependent-type languages like Idris.

Types are proofs in OCaml as well, you don't need dependent types to have
Curry-Howard correspondence. You could even prove stuff in Java. And you can
ensure invariants with types in OCaml well enough.

------
ilovecaching
I still don't understand adding type checkers to dynamic languages beyond
Javascript, where there was no other alternative. I view the gradual type
checker craze as an admission that dynamically typed languages are a failed
experiment. So why would you not just switch to a language that's designed
with static typing in mind.

~~~
zem
think about it the other way, and it's an admission that statically typed
languages are a failed experiment because sometimes you really want to tell
the typechecker "look, i can't prove this at compile time but it is correct",
i.e. not have types in your code.

the designer of the stanza language has a good writeup on why stanza uses
optional types:
[http://lbstanza.org/optional_typing.html](http://lbstanza.org/optional_typing.html)

~~~
umanwizard
Well not every statically typed language is so absolutist. In C/C++ you are
perfectly welcome to cast things if you know you can prove things the
typechecker can't.

------
roel_v
Can this be run in real time in VSCode? How hard would it be to write a vim
plugin for this? I haven't done any vim scripting in a while - is it possible
nowadays to run a process asynchronously, so that you could essentially run
this tool on every keystroke?

~~~
c256
I believe that vim supports the language server protocol via a (some?)
plugin(s), and that pyrite provides a lsp mode, so you should be able to use
them together. Note that you would be running vim and node to write python
code, which seems like a lot of different languages to me, but I’m mostly an
emacs person, so...

------
Rotareti
Now that we have type hints and statically typing in Python, I hope to see an
open source Python compiler, that improves performance and produces single
file binaries.

~~~
sjellis
Nuitka has been around for a few years:

[https://nuitka.net/](https://nuitka.net/)

AIUI, this was basically a one-person effort for a long time, but the project
is now growing.

------
philonoist
But why does each company have one for their own[0]?

[0]news.ycombinator.com/item?id=19473944

------
MapleWalnut
A comparison with mypy would be helpful.

~~~
airstrike
From the README

> Pyright is typically 5x or more faster than mypy and other type checkers
> that are written in Python. It is meant for large Python source bases. It
> can run in a “watch” mode and performs fast incremental updates when files
> are modified.

------
laughingman2
Any extensions for emacs?

------
formalsystem
Does this work typecheck matrix operations?

------
mlevental
is there a way to get any of these python typecheckers to automatically
annotate my code?

~~~
igouy
Yes -- see pytype.

