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

81–90 of 220 posts

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

#81

Post by junon »

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.

I hate TS's tooling with a burning, deep passion. But its type system is actually pretty incredible for what it is.

There are times that I yearn for TS's ability to do duck type reasoning in e.g. Rust (despite that not being feasible) when working with very large data types.

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

#82

Post by marcosdumay »

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 goal is to be strict, with explicit exceptions.

You don't use a static language because you want the exceptions, but the type checking can still statically validate most of your code.

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

#83

Post by mountainriver »

SatvikBeri wrote: post #24
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?

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

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

#84

Post by dnautics »

anamexis wrote: post #45
Tade0 wrote: post #28

Earlier quoted context omitted.

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.

I do too, but I feel like TypeScript stands alone as an unusually effective and pleasant to use bolted-on type system. I've not seen any other approach come close. (My sample size is Python, Ruby and Elixir)

you don't think the elixir type system is effective? I've never seen a bolted-on type system get so much acceptance from the hardcore "you can add types into my dead hands" crowd

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

#85

Post by dminik »

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…

Have you considered these people in general aren't some outsiders out to attack you or your favorite language?

The people who do end up making and using type checkers are people who have or are actively using these dynamic languages and found out that they CAN help THEM with preventing bugs.

Also, really? 22 years in which not one type-related error happened? Never? I don't want to say I don't believe you, but I really don't.

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

#86

Post by nonethewiser »

cogman10 wrote: post #77
eloisius wrote: post #75

Earlier quoted context omitted.

Yes, where would I be without the _RelationshipBackPopulatesArgument type of sqlalchemy.orm.relationship(argument: _RelationshipArgumentType[Any] | None = None, secondary: _RelationshipSecondaryArgument | None = None, *, uselist: bool | None = None, collection_class: Type[Collection[Any]] | Callable[[], Collection[Any]] | None = None, primaryjoin: _RelationshipJoinConditionArgument | None = None, secondaryjoin: _Rela…

It's not for you, it's for your IDE. And if you aren't using an IDE then you can pretty much ignore it anyways. You are in exactly the same position as if you knew or didn't know that type.

If you're not using and IDE nor an LLM

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

#87

Post by tptacek »

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?

No? One has nothing to do with the other.

I think those of us who work in compiled languages are just snooty about them.

I'm a compiled language snoot, and happen to be working over the past couple days in typed Python for the first time. It's kind of nice. I like it. It's a huge improvement for me over ordinary Python/Ruby/Javascript; it materially improves the experience of working in the language.

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

#88

Post by nonethewiser »

thr1owaway9621 wrote: post #68
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.

I started using types with Python in 2018-ish, and I never looked back. I am not that good a programmer, so maybe I am wrong, but I just like being able to tell what the data is that's moving through the system. Typed function signatures, a little shift+k here and there, a warning that I am trying to add int and a string. I don't see what's the harm in having that? At the end of the day, if you don't want to use Pyth…

But why does your appreciate of type systesm not lead you to something like Typescript? Which is a lot more robust? Or Rust? C#?

I guess my speculation is that not every language is good at everything. Sure you might want a better type system with Rust. But for data science?

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

#89

Post by chuckadams »

eloisius wrote: post #75
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…

Yes, where would I be without the _RelationshipBackPopulatesArgument type of sqlalchemy.orm.relationship(argument: _RelationshipArgumentType[Any] | None = None, secondary: _RelationshipSecondaryArgument | None = None, *, uselist: bool | None = None, collection_class: Type[Collection[Any]] | Callable[[], Collection[Any]] | None = None, primaryjoin: _RelationshipJoinConditionArgument | None = None, secondaryjoin: _Rela…

Part of it is due to the clunky `_NoArg.NO_ARG` business for optional params. Pretty-printing it would also go a long way, but that technology seems too advanced for any language circa 2026.

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

#90

Post by falcojr »

ethagnawl wrote: post #37
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?

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.
Post reply on HN