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

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.

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.

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.

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

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

is valid python, and it does print "hi" without even so much as a warning. Personally, I don't think "print(hi)" should be a valid type.

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.

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?

If you want type checking, run mypy.

If you don't want type checking, don't run mypy.

I don't see what's so difficult. If it was technically possible to run programs that have type errors in other languages, they would have the option to ignore type errors too, because it's convenient.

Typescript also ignores errors (generating js output for you to run) by default, so what's the point if it's not enforced?

Typescript does not ignore type errors by default. Type error = fail to compile

Try it, it produces output by default. You have to add a flag/option to change this https://www.typescriptlang.org/tsconfig/#noEmitOnError

Amen.

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

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

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.

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