There is no runtime typechecking, but with an offline typechecker like mypy they're still far more than just IDE hints. In my experience you can catch most typing problems that way.

PHP went with runtime typechecking, and it isn't pretty. The type system is much less powerful than Python's because it's really hard to add complex runtime checks to an already existing dynamic language. You can make a function check whether its argument is an array, but you can't make it check whether it's, say, an array of integers, because that would require walking through the entire array, or making every array do expensive bookkeeping in case it's needed later.

If you want more complex types you have to resort to phpdoc annotations, which are only useful for offline checkers, like Python's.

When I wrote PHP we used Psalm for offline typechecking. Between that and PhpStorm the runtime checks didn't add a lot of value, and they even made mocking a lot harder at times.

On the other hand I imagine runtime checks are more useful for legacy codebases that are too messy for static analysis. I didn't work on those.

The fact you can rely on every API to allow duck typing is a core feature of the language. It has pros and cons, of course, like all features. But it is not an accident, it's by design.

And type hints have been designed with this in mind. It will stay that way.

If this is feature makes you unhappy, Python will make you unhappy. It's important to know what are the values that are important to you and chose your toolbox accordingly.

Isn't Python just a language? AFAIK there are many Python interpreters (or implementations), like CPython, Jython, IronPython,....

Couldn't a Python interpreter enforce type checking and raise errors whenever a type doesn't match? I'd be happy to use such an interpreter in many scenarios.

Tons of libs wouldn't work this way I guess, probably including stuff in the standard library. So you could really just use a subset of the Python ecosystem. I'm not sure it's worth the effort.

The standard library tends to work pretty well in general, but common libraries like boto will have problems.

Sure, you could also replace the indentation with open and close brackets, replace some keywords and change the standard lib to be like Java.

Or you could use Java which it seems is what you wanted to use in the first place and leave Python alone.

Yes, a language defined by a spec and PEP. And they define the way typing is done.

If you do it differently, you are not implementing python.

Thanks for your reply :)

> I think it should be up to the API to specify which types are allowed, not the developer just hoping it works.

This assumes:

- the dev is thinking about the API

- the dev has the knowledge and experience to do it

- the dev has the resource/constraints that allow to do so

- dev has an interest in doing so

- this is a good investment for that particular project

Thinking in black and white does not make for good language design.

I'm glad Guido designed Python and said no to so many requests to make it no Python. Because he sure been pressured to.

> When you’ve worked on a sufficiently large and complex code base maybe you’ll understand.

I do.

I also understand Python projects that have a favorable cost/benefit ratio for type hints are not that many.

When you're used to hammer you see everything as a nail, and people loving a specific language feature tend to want it everywhere.

A huge number of dev in the Python community are not professional nor even experienced programmers. And a equally big number of projects have a size or a nature that makes type hint a bad value.

When you’ve worked on a sufficiently diverse project base maybe you’ll understand.

I really enjoy being able to write about 90-95% of python with type hints, the static checking and IDE autocomplete is fantastic, and the remaining just be like "ok computer just trust me".

Or when I'm doing data wrangling in jupyter and I never use type hints cause it's all just REPL rapid prototyping and I get autocomplete from the objects.

I think type hints make sense in some specific cases. Especially if it's an external API that your code is providing, or for when the usage is not clear.

It's good for checking the internal logic, but being optional is important in the python context.

I wrestle with this too, but I think it can be useful if you understand the limitations and usefulness of it for yourself. I know that the type hints are way for me to think more carefully about what I want the functions to do and how I'd like them to respond. I'm not expecting the type checker to enforce correctness or optimize better, I'm simply hoping that the tools will help me write the best code I can for my uses. I think it's analogous to a writer working with an editor: the writer is allowed to write whatever they want, but the editor's job is to analyze it and provide suggestions to make it better. The writer has to decide what to do with those suggestions. Sometimes hinting gets in the way and I hate it, but sometimes it helps me. I try to use the help and ignore the interruptions.

Check out Pydantic: https://pydantic-docs.helpmanual.io/. It lets you define model classes and enforces the type hints of the models' fields at runtime. Plus you get free serialization/deserialization to dicts, JSON, or arbitrary Python classes. It's _really_ nice.

> There’s nothing to stop calling functions with incorrect datatypes at runtime

You can enforce typechecking of your code on the CI with a tool like `mypy` if you want additional safety. But you'll never get the same guarantees you'd get in OCaml or Rust. It's a tradeoff between flexibility and safety.

There's actually value beyond them just IDE hints. They can help expose mixed type operations (e.g. foo = int + float) and other places where you may be unintentionally casting between types. Eliminating those can result in notable performance improvements, particularly in tight loops.

You can use strict types and enforce that all types are correct during runtime. Check out mypy with "--no-any-expression" flag and Pydantic.