Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mypy 1.6

mypy-lang.blogspot.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: Mypy 1.6

#41

Post by strokirk »

_fdsfs12123 wrote: post #19

Has anyone had to choose between Mypy and Pyright? Which is "better"? A couple years ago I was in charge of choosing between the two, and I somewhat flippantly chose Pyright because it felt a lot faster ( Later, I realized that some popular libraries we use (django, numpy) have dedicated plugins for Mypy that you can't use with Pyright. So you have to look for Pyright-friendly type stubs or roll your own. I've genera…

Pyright doesn’t really support a lot of big libraries, like Django, so if you want to use them you’re out of luck.

Re: Mypy 1.6

#42

Post by mjr00 »

baq wrote: post #2

For the past year I've worked with a large JS/TS project undergoing a slow, gradual transformation into TS - before that, for the better part of past 10 years I worked on a Python 3 + some typing, lightly enforced by mypy. I must say I don't like JS, never have, likely never won't, but Typescript is a really pleasant language, even if JS underneath is more visible than I'd like. The mix of static analysis possible wi…

Python's typing ecosystem has come leaps and bounds, quickly. About 5 years ago I had to do an evaluation of Python+mypy and found that while mypy was a great idea, support by major libraries was abysmal and mypy itself was immature, so it wasn't suitable for real use. 2 years later, I took another look and the ecosystem had evolved massively, most libraries I cared about had type annotations added, PyCharm/VSCode had added support for type checking in the IDE, etc.

These days all of my use of Python is with type annotations that are validated by mypy as part of CI. It's very rare that I run into a Python library that doesn't have type annotations available. It's massively improved the stability of the Python code I'm working on. One indirect side effect is that static typing actively discourages people from poor design patterns such as **kwargs or passing around dicts/dataframes of data, since there's an obvious downside to doing so now.

Re: Mypy 1.6

#43

Post by brigadier132 »

nerdponx wrote: post #33
brigadier132 wrote: post #27

Earlier quoted context omitted.

> I find "dynamic during runtime + static during development" to be a highly potent combination Except you miss out on massive performance gains and your software runs 10x slower because of runtime type-checking. It's actually the worst of both worlds.

The point is that you don't need runtime type checking if you can trust your type checker.

No, dynamically typed languages literally have runtime type checking built in because the interpreter does not know the type of any individual object until runtime.

Everything is stored on the heap, there is no cache locality for objects so every object property access has the performance of a linked list (or hash map, not good), and all method invocations require dynamic dispatch.

What this means is your code will be slow as fuck for no reason. If your code is 100% typed and you managed to find a fully compatible compiler that actually took advantage of the type annotations you could see massive speedups and significantly lower memory usage (we are talking order of magnitude improvements).

Re: Mypy 1.6

#44

Post by VeejayRampay »

networked wrote: post #21
baq wrote: post #2

For the past year I've worked with a large JS/TS project undergoing a slow, gradual transformation into TS - before that, for the better part of past 10 years I worked on a Python 3 + some typing, lightly enforced by mypy. I must say I don't like JS, never have, likely never won't, but Typescript is a really pleasant language, even if JS underneath is more visible than I'd like. The mix of static analysis possible wi…

Do you know about Pyright? It is a Python type checker implemented in, and apparently influenced by, TypeScript. It is from Microsoft, so the influence is not that surprising. There was a recent HN submission about it: https://news.ycombinator.com/item?id=34222407 . I use Pyright as my primary type checker and mypy as a secondary. (For example, Pyright won't run in Termux on my phone. I could likely fix this, but myp…

I think by design, pyright works on single files, not whole codebases, unless you add some scripting on top of it

Re: Mypy 1.6

#46

Post by kelsolaar »

_fdsfs12123 wrote: post #19

Has anyone had to choose between Mypy and Pyright? Which is "better"? A couple years ago I was in charge of choosing between the two, and I somewhat flippantly chose Pyright because it felt a lot faster ( Later, I realized that some popular libraries we use (django, numpy) have dedicated plugins for Mypy that you can't use with Pyright. So you have to look for Pyright-friendly type stubs or roll your own. I've genera…

We started with Mypy for thr colour-science.org projects but Pyright is so much faster that it is hard to look back. We have no particular issue with Numpy. As you pointed out the devs, especially Eric Traut, are really responsive.

Re: Mypy 1.6

#47

Post by [deleted] »

imjonse wrote: post #5

In the age of most projects having animated websites, videos on the homepages, ads for courses and maybe an online conference for launching a new version, I find this use of 2006-era blogspot strangely comforting.

[deleted]

Re: Mypy 1.6

#48

Post by [deleted] »

baq wrote: post #2

For the past year I've worked with a large JS/TS project undergoing a slow, gradual transformation into TS - before that, for the better part of past 10 years I worked on a Python 3 + some typing, lightly enforced by mypy. I must say I don't like JS, never have, likely never won't, but Typescript is a really pleasant language, even if JS underneath is more visible than I'd like. The mix of static analysis possible wi…

[deleted]

Re: Mypy 1.6

#49

Post by ska »

brigadier132 wrote: post #43
nerdponx wrote: post #33

Earlier quoted context omitted.

The point is that you don't need runtime type checking if you can trust your type checker.

No, dynamically typed languages literally have runtime type checking built in because the interpreter does not know the type of any individual object until runtime. Everything is stored on the heap, there is no cache locality for objects so every object property access has the performance of a linked list (or hash map, not good), and all method invocations require dynamic dispatch. What this means is your code will b…

This was something nice about CL implementations like SBCL. When you needed fast you can fully type everything and unbox it effectivly, but it got out of your way when you didn't. Something approximating best of both worlds. Of course the fast code started to look like c, but that's not such a bad thing if you could localize it.

Re: Mypy 1.6

#50

Post by randomdata »

orangecat wrote: post #38
softirq wrote: post #12

Earlier quoted context omitted.

If you don't consider static type and built in concurrency primitives features then ok, at what point does nice to have features outweigh performance gains and the robustness of static typing that directly impacts the quality of the end user experience and the readability of the code to other developers?

readability of the code to other developers I disagree that Go's insistence on verbosity improves readability. Each individual line may simpler, but the larger purpose of the code is obscured in all the "if err != nil" weeds. My unpopular opinion is that Dart should get a lot more attention. Strong typing with null-safety, compiles to native, batteries included, and nearly as expressive as Python.

> but the larger purpose of the code is obscured in all the "if err != nil" weeds.

That's the difference between script and system programming. When writing scripts, one is only concerned about carrying out a certain task and if anything goes wrong the whole thing can bail. Systems are more robust. When things go wrong they cannot just fail. They need to recover gracefully and do something meaningful in the failed state.

Handing failure conditions is the primary purpose of system code. Irrespective of Go, there is something to be said about some kind of identifier that says "take note: this is the most important code in the application!" If that comes across as being 'weedy', you know that you really needed a scripting language, not a systems language.

Different tools for different jobs.

Post reply on HN