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

61–70 of 114 posts

Re: Mypy 1.6

#61

Post by js2 »

veber-alex wrote: post #59
_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 and ruff are my new go to python tools, replacing mypy, pylint, isort and black. So far the only thing that bothers me about pyright is that it can't infer the type of collections based on later insertions. So in something like: lst = [] lst.append(1) lst is of type list[Any] I also program in Rust so I kinda expect this to work :P I asked the maintainer about this and this is apparently by design, though myp…

Ruff is not a replacement for black[^1]. It's also currently complementary to pylint, not a replacement[^2]. I still use those tools with ruff.

Further, out of the box, ruff doesn't even replace isort. You have to specifically enable it to sort imports (`I`)[^3].

I personally think that ruff's defaults are much too conservative. I configure it with `ALL` and then ignore the rules I don't want. I _want_ upgrades of ruff which add new rules to find new things. I'll never know about the new rules if I have to follow its development. I fully expect `pre-commit autoupdate` to cause me some pain after I run it, and that's okay. Linters adding new rules are usually helping me make my code cleaner.

[^1]: https://docs.astral.sh/ruff/faq/#is-ruff-compatible-with-bla...

[^2]: https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-py...

[^3]: https://docs.astral.sh/ruff/rules/#isort-i

Re: Mypy 1.6

#62

Post by gaganyaan »

randomdata wrote: post #50
orangecat wrote: post #38

Earlier quoted context omitted.

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 st…

Go still picked a terrible option. The `?` operator in Rust is way better, proving that systems languages don't have to suffer Go's choice.

Re: Mypy 1.6

#63

Post by gaganyaan »

brigadier132 wrote: post #27
solarkraft wrote: post #10

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.

Have you tried pypy? A 10x performance hit is very much an overstatement for lots of code.

Re: Mypy 1.6

#64

Post by ronsor »

coding123 wrote: post #37
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.

no idea how blogspot has survived this long

Google can't kill it since they forgot about it

Re: Mypy 1.6

#65

Post by networked »

VeejayRampay wrote: post #45

I really wish we had a ruff equivalent for python type checking, mypy is OK but it's really slow

Pyre, written in OCaml, is the closest thing that's stable. It has been discussed on HN a couple of times. Here is the 2021 discussion: https://news.ycombinator.com/item?id=27107647.

Note that Pyre does not support Windows (https://github.com/facebook/pyre-check/issues/554) and only provides wheels for x86_64 Linux and macOS (https://pypi.org/project/pyre-check/0.9.18/#files). While I don't use Windows, it makes me reluctant to adopt it. First, I want Windows users to be able to contribute to my projects that work on Windows. Mypy and (predictably) Pyright won't create an obstacle for Windows users. Second, the limited number of platforms makes Pyre seem a little internal-toolish.

It may still be worth it. As of today, actually, one of my projects has a Pyre branch. I want to see what it is like developing with it.

Re: Mypy 1.6

#66

Post by [deleted] »

randomdata wrote: post #50
orangecat wrote: post #38

Earlier quoted context omitted.

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 st…

[deleted]

Re: Mypy 1.6

#67

Post by gen220 »

bloopernova wrote: post #24

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,…

These pages are naturally out of date from the moment they're written.

Caveats aside, I use pyright, ruff and black (although ruff will probably one day consume `black`, entirely) – that's it.

`ruff` centralizes a lot of the linter/fixer ecosystem (isort, autoflake, pylint and more). `pyright` is for GoToDefinition and type-checking. `black` is for sanity-checking what `ruff` spits out, and should hopefully not be necessary (for me) as a standalone package at some point in the near future.

Ruff is not 1.0 yet, so I wouldn't use it at work – but I use it in all my own things.

Re: Mypy 1.6

#68

Post by gen220 »

_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…

`mypy` originally had first-mover advantage, `pyright` has late-mover advantage.

Now that we're in the mid-to-late stage of Python typecheckers, `pyright` has a better intercept and slope than `mypy`.

I think there'll be one last typechecker to rule them all written in Rust – but we're not there yet, so use `pyright`.

Re: Mypy 1.6

#69

Post by cbb330 »

I have 90 PRs to Mypy configured repos this year, across 10+ python repos which are a mix of services and background jobs. All of them have some mix of pyright/jedi+ruff+black. I have implemented these tools either via CI or in my ide like experience in NVim.

TLDR; BE WARNED. this basket of bandaids is NOT a replacement for a strongly typed language. I would NOT recommend Python to teams or for services. No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. This collection of bandaids is complex to maintain, upgrade, standardize, and has infinite edge cases where type annotation errors are just wrong.

The worst part about this basket is that you get all of the above features for free and are REQUIRED with go via gopls and gofmt. Gopls "is the official Go language server developed by the Go team." good luck achieving parity of this in python.

If you implement a service/app/anything production, use anything but a dynamically typed language like python.

Re: Mypy 1.6

#70

Post by aleksanb »

KolmogorovComp wrote: post #14

Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacement with (in my case), zero downside. [0]: https://github.com/microsoft/pyright

Pyright doesn't work with Django, as Django's so dynamic that it requires a plugin to infer all types correctly. Sadly, even mypy with plugins is a mess to get set up in vscode, especially if you want it to use the same config as you use for ci checks from the command line.

We use mypy + [django-stubs](https://github.com/typeddjango/django-stubs) (in a huge Django + drf project at day job) which includes a plugin for mypy allowing it to recognize all reverse relations and manager methods. Mypy is still really rough around the edges. The cli args are poorly documented, and how they correspond to declarations in a mypy.ini / pyproject.toml is mysterious. Match-statements still have bugs even a year after release. Exclusion of untyped / partially typed files and packages we've had to solve with grep filtering mypy's output for our whitelisted set of files, as it's been unable to separate properly between errors you care about (in your own codebase) and errors in others code (dependencies, untypable dynamic python packages etc).

The largest issue IMO is that mypy tried to adapt a java / OOP style way of type system onto python, instead of recognizing the language's real power within duck typing and passing structural types around. Typescript chose the right approach here, modelling javascript the way it is actually written, favoring structural over nominal typing, instead of the archaic and now left-behind way of Java-style OOP that has influenced mypy.

There was a recently accepted PEP which allowed for limited dataclass transforms, enough to cover the @attr.s usecase for both mypy and pyright, but nowhere near expressive enough to cover django's models and ORM sadly. It's probably impossible / undesirable to allow for such rich plugins, so i see the future for proper pluginless typing to be more akin to how pydantic / normal dataclasses solve typing, by starting with a specification of the types, deriving its runtime implementation, instead of plugins having to reverse the type representation of a custom DSL.

Post reply on HN