News for hackers. Stuff that matters.
Re:Python’s “type hints” are a bit of a disappointment to me by hermitdev on Thursday April 21, 2022 @06:10PM (#31115796)
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.

Re:Python’s “type hints” are a bit of a disappointment to me by ModernMech on Thursday April 21, 2022 @08:41PM (#31116926)
> "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.
Re:Python’s “type hints” are a bit of a disappointment to me by edgyquant on Thursday April 21, 2022 @08:22PM (#31116799)
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.
Re:Python’s “type hints” are a bit of a disappointment to me by umanwizard on Thursday April 21, 2022 @09:46PM (#31117337)
In fact that quote is almost exactly the opposite of the truth. “Dynamic” literally means “at runtime”.
Re:Python’s “type hints” are a bit of a disappointment to me by tonyg on Friday April 22, 2022 @05:02AM (#31119569)
> 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.

Re:Python’s “type hints” are a bit of a disappointment to me by faho on Friday April 22, 2022 @06:58AM (#31120167)
> 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.

Re:Python’s “type hints” are a bit of a disappointment to me by tonyg on Friday April 22, 2022 @05:15PM (#31128255)
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 :-)