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.
Why if TYPE_CHECKING?
11–20 of 74 posts
Re: Why if TYPE_CHECKING?
#12I rarely butt into practices for languages that I don’t use.[1] But having a flag for “are we type-checking” is a, well, huge red flag.
[1] Except some light scripting
Re: Why if TYPE_CHECKING?
#13One 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.
The issue is that, often, without type annotations there would be no cyclic dependency (because any type matching the implicit interface would work). So by introducing type annotations (which means extra imports), you end up having to refactor quite a lot of code and the end game is a one-type-per-module-with-separate-interface-definition system of the sort encountered in, well, statically-typed languages. If you don…
I read 'Type in string' like a forward declaration. I find uses for them within a single module. They're not always hacks.
Re: Why if TYPE_CHECKING?
#14Earlier quoted context omitted.
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.
> 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):Re: Why if TYPE_CHECKING?
#15Earlier quoted context omitted.
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.
> parent-child link between two classes is a cyclic dependency What do you mean? Where is the cycle?
I also wonder. If a child class knows its concrete parent (apart from where inheritance is declared), and not just references it via super(), things have already gone badly wrong.
Re: Why if TYPE_CHECKING?
#16Earlier quoted context omitted.
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.
> 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.
Re: Why if TYPE_CHECKING?
#17Professionals 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.
Re: Why if TYPE_CHECKING?
#18> However, Python doesn’t have the compile-time check, because it’s an interpreted language that is dynamically-typed, which means its only real place to check is at runtime Pet peeve: Python is compiled (into bytecode), so it could theoretically do checks at compile time. The "dynamically-typed" part is correct and is the real reason.
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.
Re: Why if TYPE_CHECKING?
#19You 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…
> However, no IDE will show any problem with this code.
That's not entirely True... I just checked it here and Eclipse/PyDev does flag this correctly -- since version 11.0.0 ;)
See: https://www.pydev.org/history_pydev.html (Imports found inside a typing.TYPE_CHECKING will be considered undefined if the scope that uses it requires it to be available when not type-checking).
Re: Why if TYPE_CHECKING?
#20Professionals 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.
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 was simply extended to allow any random expression as a "type".
In fact:
x: print("hi") = 4