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

31–40 of 60 posts

Re: Reasons to avoid static type checking in Python

#31

Post by LarsDu88 »

baq wrote: post #28
jandrewrogers wrote: post #16

I’ve written a lot of production Python and also a lot of thoroughly and rigorously statically typed code in C++. I use both regularly but there are clear tradeoffs in this regard. The main reason to avoid static type checking is that the programming language makes it difficult to do it effectively due to trading it away for other benefits. This does not change the intrinsic value of static type checking. Python work…

I’d probably agree with you 5 years ago, but in those 5 years typescript has shown that you can take a completely dynamic language, add a very powerful and well thought out type system and the resulting language is so much better for non-trivial projects. So if you ask me, who has been programming Python since before new-style classes, if types make sense for Python, the answer is a resounding ‘yes’: just steal as mu…

And not only that, but you can take that statically typed code and build JIT compilers on top of them

Re: Reasons to avoid static type checking in Python

#32

Post by j-pb »

jongjong wrote: post #26
j-pb wrote: post #23

Earlier quoted context omitted.

Thats what I call "Uncle Bobs ossification disease" where you spend too much time on process and not enough on getting shit done. Because everything is broken up again and again it just piles and piles, making it harder to change things. Everything is intertwined through (often unwarranted) reuse and even the non-reused stuff is smeared over dozens and dozens of functions that are used only at a single call site. But…

If you saw how little code my projects require, you would realize that this is incorrect. I've built a decentralized cryptocurrency exchange that can work with most blockchains in just 5000 lines of code. Has been running for 4 years with zero bugs. I've written a cryptocurrency from scratch with only about 4000 lines of code and have not had any bug reported after 3 years of continuous operation. On the other hand,…

> I rarely need to update them.

Not really a good project to measure ossification on then.

Re: Reasons to avoid static type checking in Python

#33

Post by BiteCode_dev »

baq wrote: post #28
jandrewrogers wrote: post #16

I’ve written a lot of production Python and also a lot of thoroughly and rigorously statically typed code in C++. I use both regularly but there are clear tradeoffs in this regard. The main reason to avoid static type checking is that the programming language makes it difficult to do it effectively due to trading it away for other benefits. This does not change the intrinsic value of static type checking. Python work…

I’d probably agree with you 5 years ago, but in those 5 years typescript has shown that you can take a completely dynamic language, add a very powerful and well thought out type system and the resulting language is so much better for non-trivial projects. So if you ask me, who has been programming Python since before new-style classes, if types make sense for Python, the answer is a resounding ‘yes’: just steal as mu…

I wish we'd steal more. TS type systel and syntax is much better that what we have.

And I hope one day iter[] and callable[] will be made available, cause importing typing sucks.

Re: Reasons to avoid static type checking in Python

#34

Post by petesergeant »

BigJono wrote: post #27
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.

I don't know how you can put TS in the S-tier when the community is hell bent on making every codebase as unreadable and complicated as possible.

> when the community is hell bent on making every codebase as unreadable and complicated as possible

I don’t understand what you’re getting at, but clearly you’re expressing some pain here: what are some examples?

Re: Reasons to avoid static type checking in Python

#35

Post by petesergeant »

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

Re: Reasons to avoid static type checking in Python

#37

Post by bmacho »

th0ma5 wrote: post #13
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.

Are those tiers good or bad? What is the order?

SABCDEF descending

Re: Reasons to avoid static type checking in Python

#38

Post by a_t48 »

jongjong wrote: post #25
a_t48 wrote: post #22

Earlier quoted context omitted.

I don’t quite follow here - you can still declare interfaces (Protocol) to declare what behavior your code needs.

It doesn't work very well for generic concepts. For example, let's say I have a dependency which exposes a function which takes a URLDefinition as an argument. Maybe the dependent logic already has a similar type to represent URLs but maybe it's called URLInfo... The property names might be slightly different. Maybe URLInfo has a Host and Port property starting with capital letters but URLDefinition properties are al…

`Or(URLProtocol, str)`

Regardless - this is very much a strawman. I could (try to) pick apart the example, but I'm not going to. Sometimes a complex interface is required, sometimes a simple one.

Re: Reasons to avoid static type checking in Python

#39

Post by agubelu »

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…

I agree with this. For example, it leads to weird situations where a linter with a strict type checking configuration marks some code as a type error, but it runs just fine.

Which, in turn, leads to you ignoring type errors entirely, since you don't know which one are spurious and which ones aren't.

Re: Reasons to avoid static type checking in Python

#40

Post by Thiez »

jongjong wrote: post #25
a_t48 wrote: post #22

Earlier quoted context omitted.

I don’t quite follow here - you can still declare interfaces (Protocol) to declare what behavior your code needs.

It doesn't work very well for generic concepts. For example, let's say I have a dependency which exposes a function which takes a URLDefinition as an argument. Maybe the dependent logic already has a similar type to represent URLs but maybe it's called URLInfo... The property names might be slightly different. Maybe URLInfo has a Host and Port property starting with capital letters but URLDefinition properties are al…

The approach you suggest is commonly referred to as 'primitive obsession' and is considered by many (including me) to be an antipattern. Having primitives everywhere means you have to repeat validations everywhere, methods will have more parameters, and it's much easier to accidentally pass these parameters in the wrong order.
Post reply on HN