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

Are you expected to run five Python type-checkers now?

pyrefly.org

Post reply on HN
Print view View original

91–100 of 220 posts

Re: Are you expected to run five Python type-checkers now?

#91

Post by datsci_est_2015 »

hedora wrote: post #56
datsci_est_2015 wrote: post #8

Earlier quoted context omitted.

> Just point some agents at it and you can port it. Don’t think we’re there yet, otherwise we would see a bunch of forks of major libraries to alternative languages - and not just Python. There’s still too much risk of insidious errors and bugs.

I've done thus a few times for stuff in the There's something particularly satisfying about shipping a 1-10MB static rust binary instead of a 2GiB docker python environment. (I'm talking about just porting simple applications, or maybe a missing package/crate at a time. Not both at once, and not typical 100K-10M line internal legacy sprawl)

What have you ported, for example? Any 3PL or all internal code?

Re: Are you expected to run five Python type-checkers now?

#92

Post by chuckadams »

bborud wrote: post #69
dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

Python has other, bigger problems that make it a constant headache. One of them being the dismissive attitude towards any and all of problems that come from versioning, dependencies and quirks that make it challenging to have robustness. Criticisms are typically dismissed by suggesting heaping yet another "solution" onto the growing pile of "solutions" that you have to drag around with you. That people have to learn.…

Python the language is pretty nice. It has its warts, but I make my living in PHP which is practically made of warts. But the python ecosystem still seems to be trying to figure out this whole package management and project setup thing. In most languages I can do some form of `$blub install` where $blub is the language's official package manager or some close equivalent. It's just python that always screams at me that I have to set up and "enter" a virtualenv. I get what venv is for, but it's still a weird hack of hardlinks and relative paths that no other language seems to need, and a clumsy two-step dance of a UX that hasn't improved in like 20 years.

Re: Are you expected to run five Python type-checkers now?

#94

Post by chuckadams »

falcojr wrote: post #90
ethagnawl wrote: post #37

Earlier quoted context omitted.

Yeah, I can't say I really get the appeal of gradual typing. It's commented/documented code at best and outright lies at worst. Sure, you can build tooling around it and improve your DX a bit but isn't it always a house of cards?

If you add one of these type checkers into your CI or a pre-commit hook, it provides the same guarantees you get from a compiler along with the same tooling benefits. It gives you the option of using the structure when you need it, but not being forced to use it when you want to take advantage of some of the more dynamic features of the language.

But none of the runtime benefits of having static types in the compiler, since the runtime still can't trust the types. Still, half a loaf is better than none.

Re: Are you expected to run five Python type-checkers now?

#95

Post by joha4270 »

Tade0 wrote: post #28
pmontra wrote: post #23

Earlier quoted context omitted.

Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.

Personally I like having my TypeScript cake and eating it. I also truly believe those who design type systems would benefit from taking a look what kind of code people programming in dynamically-typed languages produce.

Could you point me towards the kind of code people programming in dynamically-typed languages produce?

I have lived in statically typed languages almost all of my life, and even when I don't, I pretend I do, just without having a typechecker. So I'm very curious about what I'm missing.

Re: Are you expected to run five Python type-checkers now?

#97

Post by Animats »

dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

The modern approach seems to be to require full typing on items seen from outside the function or object. Within functions, have the compiler infer as much as it can. Newer languages (Go, Rust) seem to be converging on this approach.

Function parameters need type info as guidance for people and LLMs calling the function. Even though cross-function type inference is technically possible, it's too confusing. Long-distance inference failures tend to generate poor messages.

Within a function, if you have typed parameters, the type inference engine has a local starting point and a good chance of success on most local variables.

Unchecked advisory typing in Python was a terrible idea. All the work of writing type declarations with none of the benefits.

Re: Are you expected to run five Python type-checkers now?

#98

Post by [deleted] »

cogman10 wrote: post #40
pmontra wrote: post #23

Earlier quoted context omitted.

Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.

It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…

[deleted]

Re: Are you expected to run five Python type-checkers now?

#99

Post by sideway »

mountainriver wrote: post #83
SatvikBeri wrote: post #24

Earlier quoted context omitted.

What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.

ML is basically the one use case for Python anymore. And that even shrinks by the day

How so?

Re: Are you expected to run five Python type-checkers now?

#100

Post by stackskipton »

shevy-java wrote: post #79
cogman10 wrote: post #40

Earlier quoted context omitted.

It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…

This is even worse because you attempt to try to sell why types SOMETIMES make sense. But you aim with this for a language that did not have nor need types to begin with. People don't seem to understand that this is an issue. The library-situation is really not different from having types everywhere, and some people will do that too. > catch bugs that you might otherwise miss. People repeat this a lot. In about 22 ye…

SRE here, I've had multiple outages caused by lack of typing in both Ruby and Python where bad types get passed, something doesn't catch it and either data corruption or constant crashes. Couple cost us big money because it screwed up billing and we were forced to eat the billing cost.
Post reply on HN