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

81–90 of 114 posts

Re: Mypy 1.6

#81

Post by sgarland »

bjornasm wrote: post #77
mjr00 wrote: post #42

Earlier quoted context omitted.

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

I agree with avoiding *kwargs, but I wonder what we should do rather than to pass around dataframes if we have a program that works with dataframes? I get that there is a downside as the actual types are hidden inside the dataframes, but I am unsure if the tradeoff is worth it by unpacking the dataframe into arrays or objects for every function call and return, if the functions require them to be dataframes?

You can define nested types for args and return values:

def foo(bar: dict[int, dict[int, str]]) -> list[tuple[str]]

In older (With live checks while you write, it’s pretty easy to do this as you go.

Re: Mypy 1.6

#82

Post by bjornasm »

cbb330 wrote: post #79
bjornasm wrote: post #78

Earlier quoted context omitted.

>But at scale there are no success stories. Do you believe this yourself?

yup! along the dimensions of feature velocity and developer experience with regard to cost. of course python/ruby/javascript have succeed in bringing value to the world in general -- but in this thread we're focusing on production reliability, debugging, refactoring. as we see, dropbox is proud to admit that they hired Mypy core developers and fund the project, but guess how much they spent on the mistake of using py…

So the thousands of developers using Python either doesn't know their own best or are just in perpetual pain in their use of python? There isn't the slight possibility that your view on what is a useable programming language in production is subjective and not objective?

Re: Mypy 1.6

#83

Post by cbb330 »

bjornasm wrote: post #82
cbb330 wrote: post #79

Earlier quoted context omitted.

yup! along the dimensions of feature velocity and developer experience with regard to cost. of course python/ruby/javascript have succeed in bringing value to the world in general -- but in this thread we're focusing on production reliability, debugging, refactoring. as we see, dropbox is proud to admit that they hired Mypy core developers and fund the project, but guess how much they spent on the mistake of using py…

So the thousands of developers using Python either doesn't know their own best or are just in perpetual pain in their use of python? There isn't the slight possibility that your view on what is a useable programming language in production is subjective and not objective?

Yep! I think all of those repos will either proverbially die a hero or live long enough to see themselves as a villain.

And thats because of the fundamental tradeoff of dynamic typing vs static typing. That part no one can disagree on.

The only disagreeable part I believe I'm saying is where does the dynamic typing scale limit happen. As a polyglot developer, working a lot with junior developers, I can say that dynamic typing hits a scale limit of feature velocity / production support / cost much faster than the general folk are aware of.

Re: Mypy 1.6

#84

Post by FreakLegion »

zelphirkalt wrote: post #32
maleldil wrote: post #16

Earlier quoted context omitted.

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.

TCO is available in Python if you want it. Multiline lambdas can be had by abusing the walrus operator, but in a language that supports nested functions it's a bit pointless. Assuming you meant fluents, you can write most languages in that style if you want to, including Python.

Re: Mypy 1.6

#85

Post by mjr00 »

bjornasm wrote: post #77
mjr00 wrote: post #42

Earlier quoted context omitted.

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

I agree with avoiding *kwargs, but I wonder what we should do rather than to pass around dataframes if we have a program that works with dataframes? I get that there is a downside as the actual types are hidden inside the dataframes, but I am unsure if the tradeoff is worth it by unpacking the dataframe into arrays or objects for every function call and return, if the functions require them to be dataframes?

Sadly I haven't found any good ways to strongly type dataframes, so my solution is mainly cultural: just make people aware that they shouldn't use dataframes unless it makes sense, as opposed to Python codebases where dataframes are the default data type that gets passed around. I've tried to limit dataframe usage only to things like reading data from CSVs, then converting them to typed dataclasses before further processing.

It also depends on your use case. pandas is obviously very flexible and easy to use, so it might be worth the tradeoff to keep using it if your main use case is interactive Jupyter notebooks run by data scientists, or dealing with highly variable input data. But most of my Python is backend data pipelines that work on predictable input data, where reliability is important, so I default to dataclasses, only using pandas in rare situations with a lot of validation code surrounding it.

Re: Mypy 1.6

#86

Post by zelphirkalt »

FreakLegion wrote: post #84
zelphirkalt wrote: post #32

Earlier quoted context omitted.

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

TCO is available in Python if you want it. Multiline lambdas can be had by abusing the walrus operator, but in a language that supports nested functions it's a bit pointless. Assuming you meant fluents , you can write most languages in that style if you want to, including Python.

TCO is available if I want it? How? Do you mean writing a slow decorator, that performs some stack magic and that I need to add everywhere? Does it cover all the cases? Like mutually tail recursive functions?

Abusing the walrus operator — Well, it is abuse then and hard to read.

I actually mean: https://www.gnu.org/software/guile/manual/html_node/Paramete...

Re: Mypy 1.6

#87

Post by rand_r »

aleksanb wrote: post #70
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 f…

Did you manage to get MyPy + Django to work together usefully? I tried the plugin you mentioned but it still seemed stymied by the dynamic nature of Django (reverse relations, etc), so I gave up on it.

If it’s actually possible to live in typed nirvana with Django I’ll bang my head against the wall some more.

We’re using Django 3.2 btw + FactoryBoy.

Actually there’s a number of annoyingly dynamic Python libraries out there where methods are created dynamically that it feels a bit like playing whack-a-mole. Is the situation like TypeScript where you need a MyLibrary.types.ts for each library?

Re: Mypy 1.6

#88

Post by rixed »

cbb330 wrote: post #83
bjornasm wrote: post #82

Earlier quoted context omitted.

So the thousands of developers using Python either doesn't know their own best or are just in perpetual pain in their use of python? There isn't the slight possibility that your view on what is a useable programming language in production is subjective and not objective?

Yep! I think all of those repos will either proverbially die a hero or live long enough to see themselves as a villain. And thats because of the fundamental tradeoff of dynamic typing vs static typing. That part no one can disagree on. The only disagreeable part I believe I'm saying is where does the dynamic typing scale limit happen. As a polyglot developer, working a lot with junior developers, I can say that dynam…

What would happen to our 10x advantage if every tech would suddenly believe you and leave scripting languages in the toy box?

Re: Mypy 1.6

#89

Post by cosmojg »

js2 wrote: post #61
veber-alex wrote: post #59

Earlier quoted context omitted.

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

What does your pyproject.toml (or equivalent) look like? Which linters, formatters, and similar tools do you consider essential to your Python development workflow?

Re: Mypy 1.6

#90

Post by guappa »

gen220 wrote: post #68
_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`.

Why would a typechecker written in rust be able to implement a different logic than one written in any other language?

And one written in python could just use python for the grammar so it would have the advantage of always loading the code the same exact way as python does.

Post reply on HN