On one hand it's nice that there's a standard way to specify types in Python now, but TBH, if I'm going through the trouble of specifying types then I'm going to use a language that has them built in and fully exploits them. In particular, not using them for performance tuning seems like a big miss.
What I can't reconcile with myself is, if I'm going to add type hinting in Python, why not use a language where my efforts of adding type hints result in performance gains? I get why it's nice for a team, but it seems like a lot of work for half the potential benefit of a typed language.
> recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide.
I write Python in my day job and I _always_ start with types. I find they make even prototype code so much easier to reason about. It's just nice to be able to tell at a glance what a function returns, what args it takes, etc., and I don't have to master Sphinx's cryptic syntax (which I still haven't managed after using it for 5 years). And I experience this benefit even for code that I wrote yesterday without even running the type checker. And it's only going to get better with editor integration.
Without types, if I have the code `a = foo(x=1)` then I have to hunt down the source file for `foo()`, which likely just returns `bar(x)`, so I have to hunt down the source file for `bar()` to figure out what the hell its return type is, and so on and so forth. With types, I just look at the type signature for `foo()` and I'm good to go (and again, editor integration means that I don't even need to look up `foo()` at all!).
100% agree - never really understood the movement behind adding types to Python. Type hints are a useless complexity that yield little return. If you want types, use something else other than Python. The whole thesis behind Python is simple is better than complex.
I don't think typing is the main obstacle to Python performance, otherwise it wouldn't be that much slower than JavaScript. In fact, there are several alternative interpreters that are much faster, but they entail incompatibilities with popular packages. Static typing cannot fix this.
Now, my dream would be for Python to actually enforce type annotations at runtime when they exist. Maybe add some kind of syntax to avoid doing it when it's expensive, e.g. `list[nocheck int]`, but for the love of god, enforce it, otherwise I feel like I'm just peppering my code with limp suggestions that only stand if some third party package can find all paths that lead to them, at which point I'd rather use a true statically typed language where the whole system doesn't look and smell like a janky afterthought.
The optional typing in Python is pretty mediocre, especially in comparison to something like Typescript that just does everything so much better. The types are pretty limited and not very ergonomic (especially when using generics or functions), and third party support is hit-and-miss. The worst thing, I think, is that the Python typing community are trying to solve lots of the problems with plugins rather than by improving the capabilities of the type system. This might produce better results in the short run, but in the long run it makes things more complicated, as for a given project I need to understand (a) how Python works, (b) how Python types work, and now (c) how each of the plugins installed in this project work and how they interact.
I really want to like typed Python, but it's a pale shadow of what it could be, and what it really needs to be if people want to use it to describe very dynamic Python programs.
Isn't it the case that Python allows for type specifier (type hints) since 3.5, albeit the CPython interpreter ignores them? The JIT might take advantage of them, which ought to improve performance significantly for some code.
That what makes Python flexible is what makes it slow. Restricting the flexibility were possible offers opportunities to improve performance (and allows for tools and humans to spot errors more easily).
I understand why they do it, but I don't like speed over usability as a default. I would rather be able to tighten up the execution via a few declarations, compiler options, etc., if necessary, but have the default be maximum flexibility, detail for debugging, etc.
I like the typechecker mostly because it's easy to use a few type annotations to do things that would otherwise require loads of unit tests.
My rule of thumb these days is, "Python is fast enough, without proof otherwise."
I don't disagree but I wish Python had builtin support for runtime type checking. I've thought about switching to Go or Rust for certain projects but Python's rich ecosystem makes it hard for me to switch, so for now I long for runtime type checking without needing an external library (e.g typeguard).
I sometimes wish I had types in Python. It makes me feel better knowing for sure what a function is returning, or what types I'm comparing. I love Pyton/Ruby and other dynamic languages, but I miss the C++ type system when using them.
Then types in python are not expressive enough. Other languages most of the time you don't even necessarily need to specify the types - the compiler/interpreter can figure it out and still type check the program.
The issue though is that Python's type annotation is not a substitute for type checking. Annotations are optional and can be inaccurate.
That's fine, this is part of the design of Python. However strict type systems are a benefit of other languages, that may not fit Python. Type annotation shouldn't be considered an alternative to a type system.
I don't want to turn Python into a statically typed language. I think there's valid criticism to be made about the flaws of its type hinting (as does the article's author), and I cannot help but compare its usefulness to static type checking.
I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.
Have you actually spent time adding type annotations to existing python code? In my experience it's a huge pain compared to other languages. Documentation is sloppy about types because people aren't used to worrying about them, so even looking at the code it's really hard to even determine the actual types of things without just running it and poking around.
Sure, I agree with that. More libraries supporting types would be great. I don't know why they don't, it's not like they need to support any Python versions that don't support types... I guess most just haven't gotten around to it.
reply