Live data from Hacker News

Mypy 1.6

mypy-lang.blogspot.com

31–40 of 114 posts

Re: Mypy 1.6

#31
post #30

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.

And yet machine code is basically untyped and fully dynamic. The world of computing is a strange place.

Machine code is type erased, not really untyped.

Re: Mypy 1.6

#32

Earlier quoted context omitted.

In fairness, if you are choosing a language based on language features, you are not going to choose Python either.

Why not? The ecosystem might as well be a language feature, and Python has one of the strongest for a lot of areas, not just ML. Also, what is Python lacking that other languages have? It's expressive and fast to develop, and with type hints and linters, reasonably robust. My main complaint is performance, but I'll take the speed to write most days.

TCO, multiline lambda, fluids/parameters, to name a few.

Re: Mypy 1.6

#33

Earlier quoted context omitted.

I find "dynamic during runtime + static during development" to be a highly potent combination because it largely prevents dumb programming mistakes and enables rich IDE hints while still allowing for enough magic to build beautiful interfaces. While they are usually a great benefit and easy enough to so, sometimes getting types just right can be more of an effort than it's worth - it's beautiful that in those cases y…

> 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.

Re: Mypy 1.6

#34
post #30

Earlier quoted context omitted.

And yet machine code is basically untyped and fully dynamic. The world of computing is a strange place.

Machine code is type erased, not really untyped.

If you squint, you could say the same about Python code that's been checked with Mypy.

Re: Mypy 1.6

#35
post #8

I work on a monorepo and MyPy and Flake8 was such a PITA at first but after you use it for a while, you really see the value of type checking. Makes unit testing better and the code more robust in general. MyPy is seriously a great tool, especially with pydoc enforcements.

At that point, why not just use Go? It's designed to feel dynamic, provides concurrency primitives out of the box, and it's orders of magnitude faster for most tasks.

I've introduced mypy to a project in the past. It was part of taking an older, low quality code base and stabilizing it into something useful. Sometimes you can't just throw it all away and start over and need a gradual approach that will start paying some dividends immediately. mypy fits that bill.

Re: Mypy 1.6

#36

Somewhat offtopic, does anyone have a link to a page that describes which extensions/tools I should be using with VSCode to author Python code? Edited to add: when you read various recommendations, they're all discrete and don't have the overall context. e.g. I installed the VSCode suggested extensions, but then read a comment that I should really be using Ruff. OK, that's good, but if I have extensions X, Y, and Z,…

the default extension is good enough to begin with. as you are adding more to your project (e.g. black/isort/django), you can naturally find more extensions.

Re: Mypy 1.6

#37
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.

no idea how blogspot has survived this long

Re: Mypy 1.6

#38
post #12
post #9

Earlier quoted context omitted.

It is a downgrade in language features, there is always PyPy.

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.

Re: Mypy 1.6

#39
post #26
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.

Also has what the product actually IS in the header and everything! "Updates about mypy, an optional static type checker for Python"

But why would you want to learn that without having to wade through dozens of pages? Crazy talk.

Re: Mypy 1.6

#40

Somewhat offtopic, does anyone have a link to a page that describes which extensions/tools I should be using with VSCode to author Python code? Edited to add: when you read various recommendations, they're all discrete and don't have the overall context. e.g. I installed the VSCode suggested extensions, but then read a comment that I should really be using Ruff. OK, that's good, but if I have extensions X, Y, and Z,…

the default extension is good enough to begin with. as you are adding more to your project (e.g. black/isort/django), you can naturally find more extensions.

One nuisance I found is that it's hard to get the VSCode Pyright to apply the same rules as the command-line one, which is very annoying when your IDE says the code is okay but it fails on CI. Not sure if that's fixed yet.
Post reply on HN