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

51–60 of 74 posts

Re: Why if TYPE_CHECKING?

#51

Post by guappa »

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.

Re: Why if TYPE_CHECKING?

#52

Post by gpderetta »

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.

It is not so much that it is fuzzy, it is that the two definitions are not exclusive.

A compilation translates a language to another, whether it is native code, internal bytecode, portable bytecode, or another source language. Compilation might also type check and optimize depending on the language. Interpretation executes a language; normally bytecode is executed, but pure source level interpreters exist. Native code is "interpreted" by the cpu itself of course.

For example JAVA is certainly a compiled language, but it is typically compiled to bytecode and then interpreted or JITed (which is a combined interpreter/compiler).

Re: Why if TYPE_CHECKING?

#53

Post by gpderetta »

maxcoder4 wrote: post #6
diarrhea wrote: 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.

In python it's very hard to avoid cyclic dependencies. Something as simple as a parent-child link between two classes is a cyclic dependency, and if the classes are in different files you have a car like in the blog post. This comes up especially hard when typing your codebase, because you have to name every type, and in python implementation is the interface, i.e. you can't just include a type definition file.

Parametrize the parent with the child and the child with the parent. Tie the knot after both are defined.

Re: Why if TYPE_CHECKING?

#54

Post by gpderetta »

bruce343434 wrote: post #11

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 think a type system might be successfully bolted on on Python. I think gradual typing might be made to work. I have no opinion on whether the current type system is good or not.

I do strongly believe that leaving the type checking to a third party program is a terrible idea. I also believe that it should at least be possible to opt-in to type-checking the annotations at runtime during execution (at the very least for tests).

Re: Why if TYPE_CHECKING?

#55

Post by n3150n »

mgaunard wrote: post #32

most of the Python code I've seen with type annotations appears to be significantly worse than the code without them. You're in Python. Either embrace it or use another language.

Could you expand on it? It is truly surprising for me that anyone would find code with type annotations to be significantly worse, for any reasons whatsoever.

On the contrary, I joyfully read and write code with type annotations. It is obviously very useful knowing which object types a function expects and which it will return.

Re: Why if TYPE_CHECKING?

#56

Post by n3150n »

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…

It is not. As the function `print("hi")` is executed, the argument type in this case becomes `Any`, as it would be for any other executed function.

As stated in the typing documentation [0]: "the only legal parameters for type are classes, Any, type variables, and unions of any of these types".

[0] https://docs.python.org/3/library/typing.html

Re: Why if TYPE_CHECKING?

#57

Post by bruce343434 »

n3150n wrote: post #56
bruce343434 wrote: post #20

Earlier quoted context omitted.

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…

It is not. As the function `print("hi")` is executed, the argument type in this case becomes `Any`, as it would be for any other executed function. As stated in the typing documentation [0]: "the only legal parameters for type are classes, Any, type variables, and unions of any of these types". [0] https://docs.python.org/3/library/typing.html

That's fine and all. But it runs without errors or warnings.

I can put that in main.py and do `python3 main.py` and it will simply run fine.

What is the point of this whole system if it's not enforced?

Re: Why if TYPE_CHECKING?

#58

Post by mgaunard »

n3150n wrote: post #55
mgaunard wrote: post #32

most of the Python code I've seen with type annotations appears to be significantly worse than the code without them. You're in Python. Either embrace it or use another language.

Could you expand on it? It is truly surprising for me that anyone would find code with type annotations to be significantly worse, for any reasons whatsoever. On the contrary, I joyfully read and write code with type annotations. It is obviously very useful knowing which object types a function expects and which it will return.

verbosity tends to make code worse, not better.

Re: Why if TYPE_CHECKING?

#59

Post by remram »

MereInterest wrote: post #16
remram wrote: post #10

Earlier quoted context omitted.

> parent-child link between two classes is a cyclic dependency What do you mean? Where is the cycle?

The parent holds a reference to the child. The child holds a reference to the parent.

Why does the parent hold a reference to the child?

Are you talking about a specific pattern or implementation detail in the interpreter? Because I would not call this "dependency"...

Re: Why if TYPE_CHECKING?

#60

Post by remram »

coryrc wrote: post #14
remram wrote: post #10

Earlier quoted context omitted.

> parent-child link between two classes is a cyclic dependency What do you mean? Where is the cycle?

class Parent: children : List[Child] class Child: __init__(self, parent: Parent):

Ah yes, it might be what they mean. I assumed inheritance. Thanks.
Post reply on HN