5 ms·

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature. In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic typing here.

edgyquant 4y ago
I get what they mean though. In a typed language you know the type of a variable at compile time. In dynamically typed languages there is nothing to enforce this and a variable can be passed with any type. So there wording may be off but the point stands.
ModernMech 4y ago
> "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. I read the sentence as "you don't know the real types of variable at [the start of] runtime" as opposed to "you don't know the real types of variable *during* runtimes" So I understood the author to mean what you said. Could have been clearer you're right.
School-Cotton 4y ago
In fact that quote is almost exactly the opposite of the truth. “Dynamic” literally means “at runtime”.
tonyg 4y ago
> 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.
- faho 4y ago
  > 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.
  - tonyg 4y ago
    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 :-)

edgyquant 4y ago

I get what they mean though. In a typed language you know the type of a variable at compile time. In dynamically typed languages there is nothing to enforce this and a variable can be passed with any type. So there wording may be off but the point stands.

ModernMech 4y ago

> "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. I read the sentence as "you don't know the real types of variable at [the start of] runtime" as opposed to "you don't know the real types of variable *during* runtimes" So I understood the author to mean what you said. Could have been clearer you're right.

School-Cotton 4y ago

In fact that quote is almost exactly the opposite of the truth. “Dynamic” literally means “at runtime”.

tonyg 4y ago

> 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.

faho 4y ago
> 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.
- tonyg 4y ago
  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 :-)