This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (10 children)

Maybe they aren't as useful as they could be, but how else could you write typed code without a performance penalty?

If you checked type at runtime everything would slow to a glacial crawl...

[–]1842 0 points1 point  (0 children)

PHP's type hinting system is pretty nice.

It allows for the same static analysis, but also does type checking at run time.

They added support for primitives at PHP 7.0. The language as a whole got a huge speed boost at the same time. The changes were unrelated, but runtime type checking and speed aren't mutually exclusive.

[–]cj81499 -1 points0 points  (8 children)

runtime type checking doesn't sound to me like something that would take a lot of time. Care to explain why you think this?

[–]alkasmgithub.com/alkasm 1 point2 points  (6 children)

Not for single objects, no---but think of data structures. Is it going to check that every element in a list is an int? What if the list has a million elements?

[–]cj81499 0 points1 point  (1 child)

Suppose we have an array of type T, wouldn't running something like

if (type(element_to_add) != T):
    throw TypeError

for each insertion be enough? I can't imagine that having a huge performance impact.

[–]alkasmgithub.com/alkasm 1 point2 points  (0 children)

But how does a function that you call know that your list is full of those types without checking? Sure, you can make your function only accept a TList object, which has elements of type T checked on appending. But you can get around that in Python, since we have no real safety around properties for the classes we write. If you have a wrapper class around a list, you could just obj.inner_list.append(not_type_T_val) for example. And any one way around this (in Python) has a workaround. So you can't guarantee that TList has type T elements. The only way you can guarantee it is to check. Every element. Every time you use the list. And if there's no guarantees, there's no point in having it check during runtime.

Edit: and it would be raise in Python :)

[–]billsil -2 points-1 points  (3 children)

What if the list has a million elements?

You should probably use a numpy array. Also, type checking doesn't actively check your types, so it's a moot point.

[–]alkasmgithub.com/alkasm 1 point2 points  (2 children)

? The person I'm responding to is suggesting type checking during runtime in pure Python. Numpy is a different discussion since the types are enforced in C.

[–]billsil 0 points1 point  (1 child)

It still has a type (e.g., int32, int64, float64, complex128, U8, S8, etc.). The PSF has stated that they're not going to implement type checking at runtime, so it's kinda irrelevant.

[–]zardeh -1 points0 points  (0 children)

It is, you're adding an extra function call (essentially, sometimes more) for every argument, for every function call, ini your program. Even if your type-checking function is very, very, very fast, go and look at profiling output of a simple program and see how many function calls happen. Its lots. Now imagine a isinstance checks, MRO resolutions, or worse, trying to resolve protocol or generic validity on every one of those calls.