31 ms·

> Unlike in a strongly typed language, the python type annotations aren’t enforced. Python is a strongly typed language but type checks happen at runtime rathe

> Unlike in a strongly typed language, the python type annotations aren’t enforced. Python is a strongly typed language but type checks happen at runtime rather than ahead of time [0]. The author is correct that the type annotations aren't enforced. [0] https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

deleted 3y ago
[deleted]
tgv 3y ago
I'm not taking those arguments seriously anymore. Here's from the linked doc: > In a weakly typed language a compiler / interpreter will sometimes change the type of a variable Well, a = 1 a = "a" a = [1, a] executes without any problem, so according to that argument, Python's typing is weak. Even if you take the "dynamic but strong" argument, it only holds for a few specific operations. A function like this cannot be considered strongly typed: def f(x, y): return x + y because I can call f(1, 2) or f("a", "b") without any problem. People have been desperately wanting to claim that Python has strong typing, but it not having weak typing doesn't make it strong. They're not binary opposites.
- DarkNova6 3y ago
  I would phrase it like this: Not only is Python dynamically typed, it is strongly dynamically typed.
- uv-depression 3y ago
  I don't think there are generally agreed upon definitions of strong vs. weak, but I think a useful definition is about changing the type _while referring to the same data_ as weakness. In your Python example there, I think we can say it's dynamically + strongly typed because you're assigning the name `a` to three different objects with different types, not changing the interpretation of any actual data in memory. C would be statically + weakly typed, because you can cast the same exact data to whatever type by using `void*`. Rust is static + strong, and I can't really think of a dynamic + weak language. Probably that would be a nightmare to work in.
  - dunefox 3y ago
    > I can't really think of a dynamic + weak language. Javascript comes to mind. https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - tgv 3y ago
    You're right, there are none. The link from the GP shows several. > changing the type _while referring to the same data_ as weakness Python performs arithmetic and comparison on ints mixed with floats. In other languages, you have to cast those first. It does array subscription on a string. You could even see an expression like 3 * "x" as a type change. > I can't really think of a dynamic + weak language It depends on what you call a type, I guess. Is [1, 2] a different type than ["a", "b"]? You can't tell in Python, because there is no type declaration. That makes comparison with polymorphism moot. You can think that the type of b in a + b must be "whatever a's plus operator accepts", but I wouldn't call one or two sanity checks before adding strong typing.
- hermitdev 3y ago
  There is a difference between type _conversion_ and changing the type of a variable. In your example, there's no conversion performed. "a" is dynamically typed, it's type changes with each assignment. The interpreter does not coerce the type at any step. Your definition of "f" is no different than this in C++: template<typename T, typename U> auto f(T x, U y) -> decltype(x + y) { return x + y; } "f" is duck typed, effectively. It works fine if operator+ is well defined for "x" and "y", otherwise it fails. The difference, though is a compile time error in C++ vs a runtime error in Python (maybe a linter error with appropriate type hints).
- Dessesaf 3y ago
  Your `f` function is just polymorphic. Would you also consider the following Haskell function to not be strongly typed? add a b = a + b This is a polymorphic function that works for any type that has a Num instance (has functions `+`, `-`, `*`, etc.). Just like the python version works for any type that implements __add__(). It's just that in Haskell's case, this checking is done at compile-time and in python's case at runtime.
  - tgv 3y ago
    But, to push it a bit further: how does Haskell deal with [1, 2] + ["a", {"x": 1}]? I think it can only do that if it knows the type of both. In Python, you don't declare those types. It's just an array. The result is just another array. It's as if the arguments to the operator get cast to [Any], where Any is the union of all possible types, which is then also the result type. Or, if you want to look at it in another way: every function, class member and variable is super-hyper-extra-polymorphic, with the types limited by one or two sanity checks at runtime for a handful of operations that happen to apply to them. If my f() would avoid the addition operator sometimes, e.g. like this: def f(x, y): if somepredicate(x): return y return x + y then y can be anything when somepredicate(x) is true, and the type of f might not even be computable. The type of f certainly would never be verified by Python beyond "is it a function of two arguments". It may not be weak, but I'm not sure calling it "strong typing" makes sense.
    - dunefox 3y ago
      It is strongly typed as 1 + "1" doesn't work. This has nothing to do with knowing the types beforehand and disallowing the execution.

deleted 3y ago

[deleted]

tgv 3y ago

I'm not taking those arguments seriously anymore. Here's from the linked doc: > In a weakly typed language a compiler / interpreter will sometimes change the type of a variable Well, a = 1 a = "a" a = [1, a] executes without any problem, so according to that argument, Python's typing is weak. Even if you take the "dynamic but strong" argument, it only holds for a few specific operations. A function like this cannot be considered strongly typed: def f(x, y): return x + y because I can call f(1, 2) or f("a", "b") without any problem. People have been desperately wanting to claim that Python has strong typing, but it not having weak typing doesn't make it strong. They're not binary opposites.

DarkNova6 3y ago
I would phrase it like this: Not only is Python dynamically typed, it is strongly dynamically typed.
uv-depression 3y ago
I don't think there are generally agreed upon definitions of strong vs. weak, but I think a useful definition is about changing the type _while referring to the same data_ as weakness. In your Python example there, I think we can say it's dynamically + strongly typed because you're assigning the name `a` to three different objects with different types, not changing the interpretation of any actual data in memory. C would be statically + weakly typed, because you can cast the same exact data to whatever type by using `void*`. Rust is static + strong, and I can't really think of a dynamic + weak language. Probably that would be a nightmare to work in.
- dunefox 3y ago
  > I can't really think of a dynamic + weak language. Javascript comes to mind. https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- tgv 3y ago
  You're right, there are none. The link from the GP shows several. > changing the type _while referring to the same data_ as weakness Python performs arithmetic and comparison on ints mixed with floats. In other languages, you have to cast those first. It does array subscription on a string. You could even see an expression like 3 * "x" as a type change. > I can't really think of a dynamic + weak language It depends on what you call a type, I guess. Is [1, 2] a different type than ["a", "b"]? You can't tell in Python, because there is no type declaration. That makes comparison with polymorphism moot. You can think that the type of b in a + b must be "whatever a's plus operator accepts", but I wouldn't call one or two sanity checks before adding strong typing.
hermitdev 3y ago
There is a difference between type _conversion_ and changing the type of a variable. In your example, there's no conversion performed. "a" is dynamically typed, it's type changes with each assignment. The interpreter does not coerce the type at any step. Your definition of "f" is no different than this in C++: template<typename T, typename U> auto f(T x, U y) -> decltype(x + y) { return x + y; } "f" is duck typed, effectively. It works fine if operator+ is well defined for "x" and "y", otherwise it fails. The difference, though is a compile time error in C++ vs a runtime error in Python (maybe a linter error with appropriate type hints).
Dessesaf 3y ago
Your `f` function is just polymorphic. Would you also consider the following Haskell function to not be strongly typed? add a b = a + b This is a polymorphic function that works for any type that has a Num instance (has functions `+`, `-`, `*`, etc.). Just like the python version works for any type that implements __add__(). It's just that in Haskell's case, this checking is done at compile-time and in python's case at runtime.
- tgv 3y ago
  But, to push it a bit further: how does Haskell deal with [1, 2] + ["a", {"x": 1}]? I think it can only do that if it knows the type of both. In Python, you don't declare those types. It's just an array. The result is just another array. It's as if the arguments to the operator get cast to [Any], where Any is the union of all possible types, which is then also the result type. Or, if you want to look at it in another way: every function, class member and variable is super-hyper-extra-polymorphic, with the types limited by one or two sanity checks at runtime for a handful of operations that happen to apply to them. If my f() would avoid the addition operator sometimes, e.g. like this: def f(x, y): if somepredicate(x): return y return x + y then y can be anything when somepredicate(x) is true, and the type of f might not even be computable. The type of f certainly would never be verified by Python beyond "is it a function of two arguments". It may not be weak, but I'm not sure calling it "strong typing" makes sense.
  - dunefox 3y ago
    It is strongly typed as 1 + "1" doesn't work. This has nothing to do with knowing the types beforehand and disallowing the execution.