Hacker News new | past | comments | ask | show | jobs | submit login

> One doesn't know the real type of a variable until runtime.

In the program

    def x(f):
        return f(3)
what is the "real type" of `f` at runtime; say, at the instant just before the call to `f`? How can you tell?

If your answer is that `f` has type "function-like", then that's a much weaker kind of a type than even type hints offer, let alone a real type system.




> what is the "real type" of `f` at runtime; say, at the instant just before the call to `f`? How can you tell?

We can tell by looking at what python triggers TypeErrors for.

>If your answer is that `f` has type "function-like", then that's a much weaker kind of a type than even type hints offer, let alone a real type system.

f implements the Callable interface - meaning it's either a function/method or an instance of a class with a `__call__` method.

So you can pass e.g. `print` or an object with a `__call__` method. If you try to do `x(5)` that's an immediate runtime TypeError because `5` can't be called.

f must also accept one int argument. It can have additional optional arguments, and it can also accept other types (e.g. `f("foo")` can also work!), but it must work on one int. The one int can already be optional - the function can also work with zero arguments.

Calling e.g. `"foo".join(5)` fails with a TypeError because 5 isn't Iterable, and calling `"foo".join([1], [2])` fails with a TypeError because it gets more arguments than expected.


Right, "function-like". I thought OP was meaning the static type of a variable, which genuinely can't be known fully at runtime in general. But it turns out that they meant to write "... until runtime", not "... at runtime", which makes this all a bit moot. And invites more confusion about the two disjoint usages of the word "type" in the PL community, as seen liberally spattered about elsethread, but that can't be helped :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: