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

Why if TYPE_CHECKING?

vickiboykis.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Why if TYPE_CHECKING?

#61

Post by durumu »

guappa wrote: post #51
albertzeyer wrote: post #8

You should also add this: from __future__ import annotations Then you will not get this error (NameError: name 'Sequence' is not defined) because it will not need the reference to `Sequence` for the annotation but the annotation is simply a string. Using `if TYPE_CHECKING` is also useful when you want to speed up the module load time by not importing unnecessary modules (unnecessary at module load time). And then, al…

Adding that will break every single runtime typechecking module. Which is why in the end it was never included in python proper. If you don't do runtime typechecking in the entire program, sure.

It kind of works, you just have to use `typing.get_annotations(func)` instead of `func.__annotations__`. Although if you aren't importing the types used in your annotations that isn't going to work... I would guess that's rare in practice.

Re: Why if TYPE_CHECKING?

#62

Post by mgkimsal »

bruce343434 wrote: post #26
mgkimsal wrote: post #21

Earlier quoted context omitted.

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.

The backwards compatibility has broken some - I think mostly visibly noticeable between 5.6 and 7.0. And every release there's some deprecations introduced that will eventually break in future. Many complex applications in 5.6 won't run 100% error free in 8.2, for sure. I'm working with a company to move from 5.6 to 7.4 and there's very little that doesn't work in the main code. Their earlier version of Doctrine was using a class called 'Null', and internally (unrelated to doctrine) they had a class named 'Null' - those had to be renamed. That took all of about 2 minutes. Upgrading Doctrine version got us to a version that removed the Null class name there too.

Python also broke backwards compatibility with their v3 release years ago. Unsure why breaking backward compatibility is being called out here(?).

But yeah, overall, it's struck me that PHP has introduced more and stricter typing rules with surprisingly little impact (compared to what could have been, of course).

Re: Why if TYPE_CHECKING?

#63

Post by mgkimsal »

n6242 wrote: post #28
mgkimsal wrote: post #21

Earlier quoted context omitted.

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.

> 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...

Do you mean mypy is optional?

At the risk of opening a can of worms here, what's "horrible"?

In your own PHP code, you can get by without any typing at all. If/when you start to use 3rd party libraries, that may become a factor, though off the top of my head I can't think of a show stopper.

Re: Why if TYPE_CHECKING?

#64

Post by durumu »

the_af wrote: post #46
spinningslate wrote: post #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…

I agree with the gist of your comment. I will add that, in my experience, having type annotations that are unreliable, cumbersome, with so many edge cases and requiring this kind of magic (e.g. "if TYPE_CHECKING", etc) which is beyond most "casual" Python users effectively means type annotations are a very hard sell for most non-hardcore team mates. I've been in a position to try improving processes and code quality…

I think type annotations are extremely valuable even if you don't use mypy. On my team we basically use them as comments that are understood by the IDE, but aren't enforced. Of course comments can lie, but appeasing mypy really is a lot of work, and I would generally rather have a slightly dishonest but mostly correct type hint than some TypeVar monstrosity or, worse, Any.

Re: Why if TYPE_CHECKING?

#65

Post by vbezhenar »

bruce343434 wrote: post #20
vbezhenar wrote: post #17

Earlier quoted context omitted.

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

But it is its own thing that compiles down to javascript, and is otherwise syntactically and semantically "very very similar" to javascript. It IS always statically typechecked and has good, or at least well defined, semantics for typing. Typescript does not change base javascript. It really is a well separated layer on top of javascript. The way python does it is different. There's no "typethon". The python grammar…

Typescript "compilation" is just stripping out types, mostly. JavaScript is a subset of TypeScript (mostly). There was even a proposal to extend JavaScript comments syntax, so all typescript types would become comments (so you could just run typescript code with JS interpreter).

Re: Why if TYPE_CHECKING?

#66

Post by remram »

SlimTim10 wrote: post #18
remram wrote: post #9

Earlier quoted context omitted.

TypeScript is also interpreted, and does type checking without running code. Their argument is very weird.

That's an odd thing to say. The distinction between compiled and interpreted languages is very fuzzy, but TypeScript is clearly on the compiled side.

Likewise, the Python typing annotation language could very well be on the compiled side...

Someone took the interpreted JavaScript language, added typing syntax on top, and typing can be checked statically.

The Python team took the interpreted Python language, added typing syntax on top, and here we are reading a claim that it can't be checked statically because it's interpreted. You understand my puzzlement.

Re: Why if TYPE_CHECKING?

#67

Post by the_af »

durumu wrote: post #64
the_af wrote: post #46

Earlier quoted context omitted.

I agree with the gist of your comment. I will add that, in my experience, having type annotations that are unreliable, cumbersome, with so many edge cases and requiring this kind of magic (e.g. "if TYPE_CHECKING", etc) which is beyond most "casual" Python users effectively means type annotations are a very hard sell for most non-hardcore team mates. I've been in a position to try improving processes and code quality…

I think type annotations are extremely valuable even if you don't use mypy. On my team we basically use them as comments that are understood by the IDE, but aren't enforced. Of course comments can lie, but appeasing mypy really is a lot of work, and I would generally rather have a slightly dishonest but mostly correct type hint than some TypeVar monstrosity or, worse, Any.

Hm. Type annotations as comments is the ultimate annoyance to my coworkers. They really do see them as "what's the point" in that case. Plus, like you say, they are misleading. The look like code, but they don't do anything.

Re: Why if TYPE_CHECKING?

#68

Post by durumu »

the_af wrote: post #67
durumu wrote: post #64

Earlier quoted context omitted.

I think type annotations are extremely valuable even if you don't use mypy. On my team we basically use them as comments that are understood by the IDE, but aren't enforced. Of course comments can lie, but appeasing mypy really is a lot of work, and I would generally rather have a slightly dishonest but mostly correct type hint than some TypeVar monstrosity or, worse, Any.

Hm. Type annotations as comments is the ultimate annoyance to my coworkers. They really do see them as "what's the point" in that case. Plus, like you say, they are misleading. The look like code, but they don't do anything.

I think if you're already documenting function argument types, there is no point. But in my experience it's unworkable to ask people to write full documentation for every function, but requiring type hints is not as hard and is nearly as useful. It is a little weird that they look like code, but I think you get used to it.

Re: Why if TYPE_CHECKING?

#69

Post by guappa »

durumu wrote: post #61
guappa wrote: post #51

Earlier quoted context omitted.

Adding that will break every single runtime typechecking module. Which is why in the end it was never included in python proper. If you don't do runtime typechecking in the entire program, sure.

It kind of works, you just have to use `typing.get_annotations(func)` instead of `func.__annotations__`. Although if you aren't importing the types used in your annotations that isn't going to work... I would guess that's rare in practice.

If you define a class inside another class or a function, get_annotations() will never be able to resolve it and just return a string, which is not very useful.

Re: Why if TYPE_CHECKING?

#70

Post by guappa »

ericvsmith wrote: post #24

PEP 649 “Deferred Evaluation Of Annotations Using Descriptors” should result in vastly reducing the need for TYPE_CHECKING. https://peps.python.org/pep-0649/

It will also break any runtime typecheck module that you might want to use.
Post reply on HN