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

71–80 of 114 posts

Re: Mypy 1.6

#71

Post by linkdd »

cbb330 wrote: post #69

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…

> No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language.

Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever.

The "static typing above all else" cargo cult is getting ridiculous.

Re: Mypy 1.6

#72

Post by cbb330 »

linkdd wrote: post #71
cbb330 wrote: post #69

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…

> No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever. The "static typing above all else" cargo cult is getting ridiculous.

It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor.

You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checkin.... because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used instead of a typed language.

Re: Mypy 1.6

#73

Post by linkdd »

cbb330 wrote: post #72
linkdd wrote: post #71

Earlier quoted context omitted.

> No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever. The "static typing above all else" cargo cult is getting ridiculous.

It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor. You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checkin... . because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used in…

I'm not saying that static typing has no value, it certainly does.

But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.

Re: Mypy 1.6

#74

Post by diarrhea »

pjmlp wrote: post #15
randomdata wrote: post #13

Earlier quoted context omitted.

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

Python is quite rich in language features, C++ like, most people tend to think it is like BASIC, but it definitly isn't.

Yep. Some people complain about C# having too many bells and whistles these days, but Python matches almost 1:1 in language features. It’s vast.

Re: Mypy 1.6

#75

Post by diarrhea »

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

I had started using mypy a couple years ago and simply never looked back at the decision. I perceived pyright as a Microsoft-specific tool, and waved it off, as mypy seemed the blessed and eventually converged-upon target.

Turns out that’s wrong so far. Tons of people advocating for the latter.

I quickly looked at the two repos. Pyright has 30 open issues. Mypy is at 2200. That is a simplistic metric, but an immense difference in any case.

Re: Mypy 1.6

#76

Post by cbb330 »

linkdd wrote: post #73
cbb330 wrote: post #72

Earlier quoted context omitted.

It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor. You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checkin... . because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used in…

I'm not saying that static typing has no value, it certainly does. But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.

I'm rejecting all dynamically typed languages *for production*. Where production means anything that needs to exist for a long time and is supported by a team. A litmus test for whether an app is production is if you actually need mypy, pyright, jedi, to effectively work on the repo.

Python is great for single developer experience and going fast as a single developer. I use it every day, willingly, in jupyter notebooks. But at scale there are no success stories. You are zoomed in on the present success of "engineering miracles" and ignoring the big picture that the application would have moved faster if they had the foresight to choose a typed language.

Hence, why i'm saying be warned on following the path of mypy+black+pyright+ruff+etc., since you will be doomed to patching on top of a fundamental flaw of the language.

I highly recommend to avoid Python for production apps especially if it is your free will (and not a matter of refactoring or rewriting existing mistakes).

Re: Mypy 1.6

#77

Post by bjornasm »

mjr00 wrote: post #42
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 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?

Re: Mypy 1.6

#78

Post by bjornasm »

cbb330 wrote: post #76
linkdd wrote: post #73

Earlier quoted context omitted.

I'm not saying that static typing has no value, it certainly does. But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.

I'm rejecting all dynamically typed languages *for production*. Where production means anything that needs to exist for a long time and is supported by a team. A litmus test for whether an app is production is if you actually need mypy, pyright, jedi, to effectively work on the repo. Python is great for single developer experience and going fast as a single developer. I use it every day, willingly, in jupyter noteboo…

>But at scale there are no success stories.

Do you believe this yourself?

Re: Mypy 1.6

#79

Post by cbb330 »

bjornasm wrote: post #78
cbb330 wrote: post #76

Earlier quoted context omitted.

I'm rejecting all dynamically typed languages *for production*. Where production means anything that needs to exist for a long time and is supported by a team. A litmus test for whether an app is production is if you actually need mypy, pyright, jedi, to effectively work on the repo. Python is great for single developer experience and going fast as a single developer. I use it every day, willingly, in jupyter noteboo…

>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 python?

twitter, famously an advocate for Ruby, spent an ungodly amount of engineering to work around ruby, hit a wall, and switched to JVM.

Just the fact that mypy and typescript exist and have exploded in adoption is proof that eng. teams very quickly hit a sand pit when using dynamic typed languages. Mypy being funded by dropbox, Typescript funded by microsoft, shows the level of investment needed to support these dynamic languages.

Re: Mypy 1.6

#80

Post by sgarland »

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…

Python has excellent exception handling, and its corollary to if err != nil would be try/except blocks everywhere.

That said, I hate Go for unrelated reasons, and love Python.

Post reply on HN