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

Reasons to avoid static type checking in Python

typing.readthedocs.io

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Reasons to avoid static type checking in Python

#51

Post by jowf8fa9sdf »

MrJohz wrote: post #21
treflop wrote: post #12

Personal opinion here but I’d put TypeScript in the S-tier for “static typing overall enjoyable-ness,” Java in D-tier and it pains me to say Python in F-tier.

Yeah, I've recently removed type checking in a Python project because it was causing more false positives than true positives, and working around the type checker's complaints was just getting too tedious. I'm a big fan of type checking in general, and Typescript is a great example of a type checker that allows you to statically define all the dynamic idioms that you'd normally use. But for various reasons, that just…

Have you tried pyright? I find it way better than mypy.

Re: Reasons to avoid static type checking in Python

#52

Post by rich_sasha »

petesergeant wrote: post #35
rich_sasha wrote: post #29

There are cars and motorbikes, and many other things. They have different benefits and costs. Python is a motorbike. It is small, convenient, nippy, fuel-efficient. It is also terribly unsafe, holds no luggage and no protection from the weather. Statically-typed languages are cars. Stable, safe, predictable, require a lot of infrequent maintenance, weather-proof. Not convenient in heavy traffic, but hey, you put on t…

To steal someone else’s comment from above, I feel like TypeScript has disproved this, and that you lose almost nothing and gain a huge amount with a high-quality optional typing system

Maybe. I don't use typescript, and rather this is my impression of state of things in Python.

Anything, including gradual typing, can be done well or not well.

Re: Reasons to avoid static type checking in Python

#54

Post by librasteve »

Python is a tool that is meant to serve you. Python is a big tent, multi-paradigm language that generally allows you to do things in the way that best suits your needs, as best determined by you.

^^ this excerpt from the post made me spit my wine out ... this is what https://raku.org is for!

Surely, according to the zen of python https://peps.python.org/pep-0020/, the pythonic way is:

There should be one-- and preferably only one --obvious way to do it.

At least raku is architected on consistent class types from the get go so its gradual typing is not just an annotation / type hint bolt on.

Re: Reasons to avoid static type checking in Python

#55

Post by MrJohz »

jowf8fa9sdf wrote: post #51
MrJohz wrote: post #21

Earlier quoted context omitted.

Yeah, I've recently removed type checking in a Python project because it was causing more false positives than true positives, and working around the type checker's complaints was just getting too tedious. I'm a big fan of type checking in general, and Typescript is a great example of a type checker that allows you to statically define all the dynamic idioms that you'd normally use. But for various reasons, that just…

Have you tried pyright? I find it way better than mypy.

When I removed the type checking stage, that was with Pyright, which I'd used because of these sorts of recommendations. It has some advantages over Mypy, sure, but it still ended up being more hindrance than help. Particularly with things being of type `Unknown`, which produced all sorts of errors that I could never properly disable.

Re: Reasons to avoid static type checking in Python

#56

Post by mharig »

roenxi wrote: post #11

Scepticism is warranted for partial type checking. Something I've noticed in partially-typed situations is they are the worst of all worlds. The type checker soaks up a lot of time, but the silly bugs that type checking would have caught still get through. Having 1 library that doesn't support type hints is a major problem if I'm trying to use a type checker. Therefore, I think "... the authors have no desire to ever…

There is such an equilibrium: type check API functions and do not clutter the rest of the code with type hints/declarations.

Re: Reasons to avoid static type checking in Python

#57

Post by tsss »

arialdomartini wrote: post #24

The wrong assumption in that page is that Static Typing implies the need for type hints or annotations. In fact, type inference is a thing. Most of the languages with Hindley Millner type system (such as oCaml, F#, Haskell, PureScript) do feel dynamic (e.g., developer does not need to hint the compiler) yet they are purely static typed. What is the argument against having Python checking the types, without asking the…

Haskell has to pay _a lot_ to achieve full type inference. A price that is way too high imo for a feature that nobody uses anyway. Among many other things it precludes subtyping, which I assume Python relies on heavily.

Re: Reasons to avoid static type checking in Python

#58

Post by alanwreath »

trashburger wrote: post #48
zokier wrote: post #46

Earlier quoted context omitted.

While there are countless cultural and technical reasons why TS ended up more successful than Python here, I think the single most significant aspect was that TS decided to go with structural system while Python went with nominal. While nominal systems in general are fairly popular and well-received, the chief thing here is that structural types match how the language was being already used. Especially for Python the…

This is my single greatest complaint about Python's type system. Protocol should have always been the primary building block rather than just being relegated to something you use for "duck typing". Subtyping fits much better with things like the dynamic approach of the Django ORM, for example.

Not sure what you mean, while it’s true that it would have been nice that Protocols were always the primary building block, as of python 3.8 they _can_ be depending on your use of Structural Typing https://peps.python.org/pep-0544/

Re: Reasons to avoid static type checking in Python

#59

Post by tome »

tsss wrote: post #57
arialdomartini wrote: post #24

The wrong assumption in that page is that Static Typing implies the need for type hints or annotations. In fact, type inference is a thing. Most of the languages with Hindley Millner type system (such as oCaml, F#, Haskell, PureScript) do feel dynamic (e.g., developer does not need to hint the compiler) yet they are purely static typed. What is the argument against having Python checking the types, without asking the…

Haskell has to pay _a lot_ to achieve full type inference. A price that is way too high imo for a feature that nobody uses anyway. Among many other things it precludes subtyping, which I assume Python relies on heavily.

I suspect almost every Haskell uses full type inference almost constantly, if only to avoid having to write out top level types by hand. I know that applies to me. I've never considered that I paid a price for it. For me it was just something that came free with a language that is nice in other ways too. What price are you seeing? (For me, absence of subtyping is a feature.)

Re: Reasons to avoid static type checking in Python

#60

Post by sgorawski »

Also, in Python (unlike TypeScript or PHP) you need to be sure that the code regularly passes type checking to have confidence in your type annotations.

I've dealt with my share of code with types that were almost correct but not really and it's been quite frustrating.

For interested I've written an article about it: https://medium.com/@sgorawski/python-types-have-an-expectati...

Post reply on HN