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

31–40 of 74 posts

Re: Why if TYPE_CHECKING?

#31

Post by tomn »

bruce343434 wrote: post #27
tomn wrote: post #25

Earlier quoted context omitted.

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.

If it catches bugs before run-time, that's a benefit to me, in the same way that testing doesn't catch all bugs (and yes, can introduce a false sense of security), but most people still think it's a good idea.

You obviously don't get the haskell experience, where if your program type checks it's probably correct, but the alternative (if, remember, you want a dynamically typed scripting language) is no type checking, which is definitely worse for some people.

Re: Why if TYPE_CHECKING?

#32

Post by mgaunard »

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.

Re: Why if TYPE_CHECKING?

#33

Post by veber-alex »

bruce343434 wrote: post #27
tomn wrote: post #25

Earlier quoted context omitted.

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.

python types can be ignored if you choose to ignore them.

Running pyright in CI/CD and in vscode has considerably improved the quality of my code, especially when refactoring.

Re: Why if TYPE_CHECKING?

#35

Post by kaoD »

remram wrote: post #9
L3viathan wrote: post #7

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

TS is not interpreted. It compiles to JS, which is interpreted, but TS itself is not. There are no TS interpreters, they all compile to JS behind the scenes.

Or does Deno run TS natively? At a glance it looks like even its runtime is written in JS[0].

EDIT: looks like they have bindings for V8[1] so yeah, just a JS interpreter behind the scenes.

[0] https://github.com/denoland/deno/tree/main/runtime/js

[1] https://github.com/denoland/rusty_v8

Re: Why if TYPE_CHECKING?

#36

Post by tomn »

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…

This feels like splitting hairs -- python and typescript are equivalent, as they are both dynamically typed languages with type annotations.

The fact that the typescript implementation does not run typescript directly, and cPython does not type check before running the code, are both implementation details.

Typescript is just a better type system on top of javascript than python's type system is on top of untyped python, because typescript is a cohesive design rather than a collection or random stuff accumulated over time.

There's no reason that couldn't have happened for python, it just didn't.

Re: Why if TYPE_CHECKING?

#37

Post by gpderetta »

kissgyorgy wrote: post #34

> However, Python doesn’t have the compile-time check Yes it does. All Python source code is parsed and compiled into bytecode. SyntaxError is raised before runtime.

I think the author is obviously talking about compile time type checks here.

Re: Why if TYPE_CHECKING?

#38

Post by lijok »

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…

> Personally, I don't think "print(hi)" should be a valid type.

And it isn't:

  a.py:1: error: Invalid type comment or annotation  [valid-type]
  a.py:1: note: Suggestion: use print[...] instead of print(...)
  Found 1 error in 1 file (checked 1 source file)

Re: Why if TYPE_CHECKING?

#39

Post by lijok »

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.

We're not professionals. We don't profess anything. Whether we want software development to become a profession is a huge topic on its own. Professions come with a ton of strings attached and oversight. Something I would personally welcome, but know most of us wouldn't.

Re: Why if TYPE_CHECKING?

#40

Post by rrdharan »

lpapez wrote: post #23
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 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.

> It was picked because it was the right tool for the job.

I think in a lot of cases only the more general form of this statement is true, i.e.:

- it is a tool

- it was picked

- there was a job

Post reply on HN