Oh ok. So it's not really static at all, they're just calling it that because it sounds better. It's simply dynamic type-checking that checks the types immediately prior to calling the function instead of checking them at the top of the function body. Offhand, it seems that the only benefit to this approach (checking prior to calling the function instead of checking inside the function) is the ability to cache the results and skip checking the same callsite in the future if nothing's changed.
Being able to significantly optimize type-checking for scripting languages like this to the point where you can actually run this in production seems quite valuable. But calling it "static type-checking" is simply wrong. Granted, they're calling it "just-in-time static", but that phrase is contradictory, it would be like saying "dynamic static type checking".
Your view of what static type checking is or isn't seems to be limited to your understanding of types (and what can be expressed with them) in Python. There's a world of languages outside Python, even for languages with dynamic typing!
I've grown to hate the phrase "static typing". It's almost as meaningless as "strong typing". While checking types compile-time certainly has it's benefits, the issue presented here is almost entirely orthogonal to that. The problem here is that strings are handled essentially as untyped opaque blobs as far as the type system is concerned. If the strings were typed properly, then both static and dynamic type systems (if otherwise equivalent) would catch the errors.
reply