Hacker News Reader

Comment by breuleux | Hacker News Reader

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.

View on HN

I was just looking at runtime type checking. Apparently the reason nobody does it is because of the roughly 30,000% slowdown compared to not doing it.

I e said it before and I’ll say it again: runtime type checking saves you from the case where you pass None instead of an actual object but not much else. How wrong would your program have to be to pass an instance of Animal instead of an instance of BankAccount? And how quickly would it error out with “giraffe does not have an attribute routing_number”?

You can’t compare to JavaScript as most JavaScript runtimes have a JIT. You’d have to compare against PyPy or something like that but it hasn’t seen anywhere near the amount of performance attention like any of the browser JavaScript engines.

Finally, CPython is very old. That means it made decisions around multithreading it still has to live with to this day whereas the JavaScript implementations have always been single threaded and added multithreading much later (learning from the experiences of other languages making the transition).

Dynamic typing is part of the problem but you’re right that it’s not the whole thing.

As far as I know, all JavaScript interpreters and JIT VMs are also single-threaded (web workers aren't real threads because they can't directly share memory with the main thread).

Web workers are real threads in the sense that they map directly to low-level threads (+ shared memory via SharedArrayBuffer which was only temporarily disabled due to Spectre).

The bigger thing is that the Python runtime has a GIL because that's kind of how you solved the problem when multiple cores started becoming mainstream in the 90s. The Linux kernel had a similar GIL. It's an easy way to technically support running in a multi-threaded environment while reducing maintenance issues at the cost that you can never use more than 1 core at a time. JS runtimes don't have this problem because the runtime support layer is almost non-existent & there's no multi-threading support at all (indeed, V8 by itself comes with almost no JS APIs - there's a clear delineation between language runtime & "app runtime"). Service workers is extremely thin & works on channels instead of shared memory, further simplifying the design. The JS GC is typically written to support concurrent multi-threaded operation to minimize the "stop the world" phase runtime whereas Python's cycle detector needs to stop the world due to the GIL. These are all small decisions that add up.

except via SharedArrayBuffer?

> my dream would be for Python to actually enforce type annotations at runtime when they exist

Does any mainstream language do this? For sure most don't, even statically-typed ones. I'm all for enforcement of types, but why does it need to happen at runtime?

But what other statically typed languages enforce static type constraints at runtime?

While it's definitely not quite the same idea, Typescript supports run-time type predicates that inform the type system.

https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

    function isFish(pet: Fish | Bird): pet is Fish {
      return (pet as Fish).swim !== undefined;
    }

Which I've found extremely useful

In python with mypy, runtime checks (e.g. assert) also inform the type system.

That's good to know -- it's a great feature for these sorts of gradual systems, in my opinion.

Flow types (for JavaScript) can be complied into run-time type-checks.

Properly statically typed languages do not need run-time checks because the compiled code is already proven to be valid by the type-checker.

> Flow types (for JavaScript) can be complied into run-time type-checks.

Okay, so there are some, though flow is pretty obscure, and flow-runtime (which is the part which does this AFAICT) is even more obscure. I don't think this is a popular feature.

> Properly statically typed languages do not need run-time checks because the compiled code is already proven to be valid by the type-checker.

If you want that, just enable strict mode for mypy.

And if you want to interface with code that is not stirctly typed, just use runtime type checks, which will inform the static type system:

   foo: Any = untyped_code()
   assert isinstance(foo, MyClass)  # after this mypy will treat foo as instance of MyClass.

Same can be done with other types of checks also.

So if you want runtime type checking that informs the type system, you have it. I certainly don't want runtime checks for what the type system has already checked for me.

> If you want that, just enable strict mode for mypy.

But I can't do that if I want to do gradual typing. If I type a function, but the type system cannot figure out what's going to call it, that's when I want it to perform a check: at the boundary.

> I certainly don't want runtime checks for what the type system has already checked for me.

The type system can remove the checks if it can prove that they always pass. My point is that if it cannot prove that they will pass, I want them at runtime.

> But I can't do that if I want to do gradual typing. If I type a function, but the type system cannot figure out what's going to call it, that's when I want it to perform a check: at the boundary.

Unless you start using # type: ignore - the only way to interface with untyped code will be to use asserts or other checks (if + throw), i.e. perform checks at the boundary.

> Properly statically typed languages do not need run-time checks

Well, what's a properly compiled language these days? Golang e.g. uses run-time dispatching due to the way interfaces work and, of course, garbage collection. Even C++ needs to do run-time dispatching of virtual methods. So the only languages left these days that do not use run-time checks are probably C and Fortran.

I mean run-time checks that the user must implement.

For example, in JS you might put these all over your code-base:

    if (typeof x !== 'string') {
      throw Error('Expected a string');
    }

This will already inform mypy that after that if statement x is type string.

Reply on news.ycombinator.com