10 ms·

Python is strongly typed. Now it has static types enforced at runtime. It’s good to be precise when there are so many quirks to expressing and checking types.

by drb91 8y ago

sametmax 8y ago
Not enforced at runtime. The Python VM does nothing with the computed type hints. It's only useful for 3rd party tools that want to check the type.s PyCharm does it natively. mypy and pyre are command line tools you can use stand alone or plug into an editor (VSCode integrate very well with mypy). But that's it.
jchw 8y ago
Huh, I thought type annotations were unused at runtime. How can I enable runtime type checking?
- computerfriend 8y ago
  You can't! Or, I guess you could do something hacky with the #!.
- hiram112 8y ago
  Even Java, which introduced generic types long after the language itself had become standardized and popular, cannot keep generic type information after compilation due to backwards compatibility. Don't quote me on it, but I believe C# doesn't have this problem.
  - saagarjha 8y ago
    But the compiler checks for this by default, so you'll get a warning unless you really break the type system.
- joshuamorton 8y ago
  There are libraries that do magic to do this. Annotations are accessible at runtime, so you can do things like add an implicit import hook that decorates every function or class with a decorator that validates the annotations.
weberc2 8y ago
> Now it has static types enforced at runtime. That's not how it works. Type annotations are ignored at runtime. And to be pedantic, even if they were evaluated at runtime, they would be dynamic types, not static types. :p The type annotations exist to make the code easier to read and to enable certain kinds of static analysis (including a type checker).
willtim 8y ago
Python is not "strongly typed". Please don't repeat this phrase near management folk. Python just gives good error messages when it crashes at runtime, e.g. "expected an Int but got a String". This is better than a segfault, but it's still a crash. Call it "strongly tagged" if you like, but "type" unqualified should mean static type. Even "dynamic type" is a marketing hijack of the word type. Professor Robert Harper takes the same position: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...
- coldtea 8y ago
  >This is better than a segfault, but it's still a crash. Strong vs weak types is orthogonal to whether there's a crash or not. The crash is because the types are dynamic (vs static) which is a different axis than strong/weak.
  - deleted 8y ago
    [deleted]
  - willtim 8y ago
    There is no static/dynamic axis for types. A dynamic "type" as you call it, is really a runtime tag. All languages are static languages. "Dynamic" and "dynamically typed" are IMHO, marketing terms. There's nothing that "dynamic" Python can do that I cannot do in a typed language using runtime tags, string keys and variants.
    - viraptor 8y ago
      Static/dynamic and weak/strong typing is about the language semamtics and the runtime. You can't reduce the description the way you do, because for every language we end up with: there's nothing I can do in X that I can't do in untyped ASM, therefore everything is untyped. Or go down to either lambda calculus or logic gates. Either works. What the language provides matters. For code like "1"+1 you have 4 main options: - strong static - doesn't compile/start due to type error - weak static - returns "11" and expression is known to result in a string at compile time - strong dynamic - crash/exception at runtime - weak dynamic - returns "11" at runtime, but the type is attached to the value, not the original expression
klibertp 8y ago
> static types enforced at runtime I'm sorry to break it to you, but that's an oxymoron. The whole idea of static types is that they don't need to be validated at runtime. Python has a static type system which is gradual (ie. allows for untyped code) and is separate from the strongly but dynamically typed semantics of Python at runtime. Now, the static type system tries to mirror the dynamic semantics wherever it can, but it's still a completely separate beast. In other words, you don't enforce static types at runtime - you enforce dynamic types at runtime as usual and have an option of additionally using static type system. By the time you run the code, the static types are mostly gone. The fact that the static types reflect the dynamic type system produces an illusion that the static types remain, but they don't. If what you said was true, the following code would not work: x: int = 0 x = "0" print(x) but it's still a valid Python code which runs just fine.
- deleted 8y ago
  [deleted]
acdha 8y ago
There's disagreement on that point and I think it's worth pondering. Python has more typing than some similar languages but less than popular static languages. I think there's an argument that the value curve for type checking has thresholds and Python hits a point where a fairly large percentage of people feel that going further starts costing more in overhead than it saves, with many projects being small enough that it's not an especially significant source of problems.

Python is strongly typed. Now it has static types enforced at runtime. It’s good to be precise when there are so many quirks to expressing and checking types.

by drb91 8y ago

Python is strongly typed. Now it has static types enforced at runtime. It’s good to be precise when there are so many quirks to expressing and checking types.

sametmax 8y ago

Not enforced at runtime. The Python VM does nothing with the computed type hints. It's only useful for 3rd party tools that want to check the type.s PyCharm does it natively. mypy and pyre are command line tools you can use stand alone or plug into an editor (VSCode integrate very well with mypy). But that's it.

jchw 8y ago

Huh, I thought type annotations were unused at runtime. How can I enable runtime type checking?

computerfriend 8y ago
You can't! Or, I guess you could do something hacky with the #!.
hiram112 8y ago
Even Java, which introduced generic types long after the language itself had become standardized and popular, cannot keep generic type information after compilation due to backwards compatibility. Don't quote me on it, but I believe C# doesn't have this problem.
- saagarjha 8y ago
  But the compiler checks for this by default, so you'll get a warning unless you really break the type system.
joshuamorton 8y ago
There are libraries that do magic to do this. Annotations are accessible at runtime, so you can do things like add an implicit import hook that decorates every function or class with a decorator that validates the annotations.

weberc2 8y ago

> Now it has static types enforced at runtime. That's not how it works. Type annotations are ignored at runtime. And to be pedantic, even if they were evaluated at runtime, they would be dynamic types, not static types. :p The type annotations exist to make the code easier to read and to enable certain kinds of static analysis (including a type checker).

willtim 8y ago

Python is not "strongly typed". Please don't repeat this phrase near management folk. Python just gives good error messages when it crashes at runtime, e.g. "expected an Int but got a String". This is better than a segfault, but it's still a crash. Call it "strongly tagged" if you like, but "type" unqualified should mean static type. Even "dynamic type" is a marketing hijack of the word type. Professor Robert Harper takes the same position: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...

coldtea 8y ago
>This is better than a segfault, but it's still a crash. Strong vs weak types is orthogonal to whether there's a crash or not. The crash is because the types are dynamic (vs static) which is a different axis than strong/weak.
- deleted 8y ago
  [deleted]
- willtim 8y ago
  There is no static/dynamic axis for types. A dynamic "type" as you call it, is really a runtime tag. All languages are static languages. "Dynamic" and "dynamically typed" are IMHO, marketing terms. There's nothing that "dynamic" Python can do that I cannot do in a typed language using runtime tags, string keys and variants.
  - viraptor 8y ago
    Static/dynamic and weak/strong typing is about the language semamtics and the runtime. You can't reduce the description the way you do, because for every language we end up with: there's nothing I can do in X that I can't do in untyped ASM, therefore everything is untyped. Or go down to either lambda calculus or logic gates. Either works. What the language provides matters. For code like "1"+1 you have 4 main options: - strong static - doesn't compile/start due to type error - weak static - returns "11" and expression is known to result in a string at compile time - strong dynamic - crash/exception at runtime - weak dynamic - returns "11" at runtime, but the type is attached to the value, not the original expression

klibertp 8y ago

> static types enforced at runtime I'm sorry to break it to you, but that's an oxymoron. The whole idea of static types is that they don't need to be validated at runtime. Python has a static type system which is gradual (ie. allows for untyped code) and is separate from the strongly but dynamically typed semantics of Python at runtime. Now, the static type system tries to mirror the dynamic semantics wherever it can, but it's still a completely separate beast. In other words, you don't enforce static types at runtime - you enforce dynamic types at runtime as usual and have an option of additionally using static type system. By the time you run the code, the static types are mostly gone. The fact that the static types reflect the dynamic type system produces an illusion that the static types remain, but they don't. If what you said was true, the following code would not work: x: int = 0 x = "0" print(x) but it's still a valid Python code which runs just fine.

deleted 8y ago
[deleted]

acdha 8y ago

There's disagreement on that point and I think it's worth pondering. Python has more typing than some similar languages but less than popular static languages. I think there's an argument that the value curve for type checking has thresholds and Python hits a point where a fairly large percentage of people feel that going further starts costing more in overhead than it saves, with many projects being small enough that it's not an especially significant source of problems.