Live data from Hacker News

Why if TYPE_CHECKING?

vickiboykis.com

21–30 of 74 posts

Re: Why if TYPE_CHECKING?

#21

Professionals should stop putting up with unprofessional tools and languages. This? This whole mess is not professional. If you want types, do not use python. Python is not a typed language. You can't just bolt on a type system, as is being live demonstrated here.

TypeScript is a good example of perfectly "bolted on" type system.

It’s a different language. Different enough to warrant a different name, at the very least.

PHP has been able to add in more typing over the same period of time and has seemed to avoid these Python problems.

Re: Why if TYPE_CHECKING?

#22
post #3

One question comes to mind: isn't cyclic dependencies something to be resolved at the root cause (remove the cycle)? It's an issue that causes various pains down the line, like type checking in this case.

Removing cycles may require extensive refactoring of the code, sometimes resulting in unintuitive layouts. All, just to solve the cyclic-import errors.

At the core of the problem is the fact that there's no thing as "partial import" in Python. When you do "from M import A" in Python, all the contents of M are evaluated and a reference to A is added to the current namespace. So, cyclic dependencies arise sooner or later, unless you adopt some very un-pythonic style for your codebase (e.g. one file per class).

Re: Why if TYPE_CHECKING?

#23

Professionals should stop putting up with unprofessional tools and languages. This? This whole mess is not professional. If you want types, do not use python. Python is not a typed language. You can't just bolt on a type system, as is being live demonstrated here.

I disagree with this opinion.

I doubt many people picked Python "because it has types". It was picked because it was the right tool for the job.

Type hints were bolted on after the fact, and even in their limited form provide TONS of value for some people (myself included).

If you don't want them don't use them, but I doubt there is a project which uses Python specificially because it has type hints.

Re: Why if TYPE_CHECKING?

#25

Professionals should stop putting up with unprofessional tools and languages. This? This whole mess is not professional. If you want types, do not use python. Python is not a typed language. You can't just bolt on a type system, as is being live demonstrated here.

It's reasonable and "professional" to want dynamically typed scripting language, for things where real types are a burden not a benefit, which also has libraries that work properly.

For me, that's the benefit of typing in python (as shonky as it is) -- you can use it to help write better library code, then ignore the types (except as accurate documentation) when using those libraries.

Maybe there are other languages that can do this, but the ones i know all have their own downsides.

Re: Why if TYPE_CHECKING?

#26

Earlier quoted context omitted.

TypeScript is a good example of perfectly "bolted on" type system.

It’s a different language. Different enough to warrant a different name, at the very least. PHP has been able to add in more typing over the same period of time and has seemed to avoid these Python problems.

I'm pretty sure that php has also explicitly broken backwards compatibility to achieve this. In general php has become far more strict over the years, which I think is a good thing. And they definitely at least sat down and thought about how to do types before adding grammar rules that allowed any random expression as the type, which is now the case in python.

Re: Why if TYPE_CHECKING?

#27
post #25

Professionals should stop putting up with unprofessional tools and languages. This? This whole mess is not professional. If you want types, do not use python. Python is not a typed language. You can't just bolt on a type system, as is being live demonstrated here.

It's reasonable and "professional" to want dynamically typed scripting language, for things where real types are a burden not a benefit, which also has libraries that work properly. For me, that's the benefit of typing in python (as shonky as it is) -- you can use it to help write better library code, then ignore the types (except as accurate documentation) when using those libraries. Maybe there are other languages…

There is, in my opinion, very little value in a type system that allows types to just be ignored. Or even a negative value, because it instills a false sense of security, because it does not actually prevent any of the mistakes that a type system is supposed to prevent.

Re: Why if TYPE_CHECKING?

#28

Earlier quoted context omitted.

TypeScript is a good example of perfectly "bolted on" type system.

It’s a different language. Different enough to warrant a different name, at the very least. PHP has been able to add in more typing over the same period of time and has seemed to avoid these Python problems.

I've had to work on a PHP project recently and it's horrible. Mypy has many pitfalls and it's not great, but at least it's entirely optional, so you can work around the issues or ignore some types until you can fix it or do some refactoring. Typescript might be a different language but it's the best implementation of adding types to a language I've seen so far.

Re: Why if TYPE_CHECKING?

#29
Small but important correction required in point 3 of the TL;DR:

> Python doesn’t care about types at runtime

This should say "Python doesn't care about type annotations at runtime."

Python _does_ care about types at runtime - but it doesn't use type annotations to compute them.

That doesn't detract from what's otherwise a really clear and helpful post. Python is living through a schizophrenic period in its evolution, and it's causing some problems. I hope it gets ironed out, though don't underestimate the difficulty. Python remains my go-to for many problems: a joy to use (for me) in many cases. But I definitely feel the need for static typing as codebase size increases. Having type annotations is good, but not being able to rely on them (i.e. static typing is not sound) adds to cognitive load and detracts from a confident development experience.

Post reply on HN