Why is typing.cast an actual function?

[arceusspike]

Why add the overhead of a function call when it adds no functionality to the program at runtime? Couldn’t we tell the type-checking program to treat the variable passed to cast as some type via some kind of inline type hint that the interpreter knows to ignore? I don’t understand why static typing would need to interfere with and degrade runtime, but I’m sure I am missing something that is obvious to others.

[JelleZijlstra]

You're welcome to propose an alternative syntax. The current syntax using a function call fits naturally in any expression, and the overhead of a simple function call is not a huge problem for much code.

You may be interested in python/cpython#27474.

[hauntsaninja]

It's also worth noting that # type: ignore is often a reasonabe zero runtime overhead alternative in situations involving typing.cast.

Not that the runtime overhead is at all meaningful ("not a huge problem for much code" is a big understatement in this case). And if you're looking to make a larger point about the effect of static typing on runtime, there are plenty other ways that typing interacts with the runtime that are much slower.

[arceusspike]

Thanks for the info! I didn’t mean to insult the development of mypy, by the way—I’m just trying to figure things out and couldn’t find an explanation elsewhere.

[carljm]

I've worked with production code where the overhead of a cast call in a hot path was sufficient to require its removal :)

Although even in that case the real problem was the overhead of constructing the runtime representation of the first argument, which required a number of __class_getitem__ calls.

[Akuli]

This might help too:

 def slow_function():
+    TargetType = Complicated[Type[Goes[Here[str]]]
+    from typing import cast
+
     for some_perf_critical_loop in foobar:
         ...
-        foo = cast(Complicated[Type[Goes[Here[str]]], bar)
+        foo = cast(TargetType, bar)
         ...

This turns slow global variable lookups (from a hashtable) into fast local variable lookups (from an array) and evaluates the slow __class_getitem__ calls before the perf-critical section. But realistically you should just use # type: ignore along with a comment about what's going on :)

[jonathanslenders]

No idea if it ever has been proposed, but what I'd like to see for cast is that it becomes a built-in that completely disappears at runtime.
Also, because that way, the first argument doesn't have to be evaluated.

[yoni-lavi]

Why can't the compiler replace cast(t, x) with x and NewType(x) with x? We could get it out of the way before the interpreter even. There should be zero overhead to that kind of thing.

As it stands, something like:

X = NewType("X", int)
s = {X(i) for i in range(n)}

is about 3-6x slower than

s = set(range(n))

even though it's an identical operation at runtime.
I would rather not have to resort to # type: ignore wherever I care about performance.

[carljm]

I agree this would be nice, but this kind of compile-time optimization is quite hard to do without breaking the (extremely flexible, maybe overly flexible, but also very well established) semantics of Python. By the time a given module using typing.cast or typing.NewType actually executes at runtime, things may have been patched such that those names refer to something entirely different than the contents of the stdlib typing module. Even builtins can be patched, so turning them into builtins doesn't solve this problem either!

[sobolevn]

There was a PR to re-implement cast in C: python/cpython#27474
But, it was never accepted.

[UltimateLobster]

Maybe this could be solved by using the annotation syntax in order to perform the casting?