7 ms·

Python is strongly typed. You want statically typed. (Instead of duck typed / dynamically typed)

jahewson 4y ago
FWIW “strong” typing is a colloquial term and lacks any precise meaning.
bzxcvbn 4y ago
Can you guess what this code does? class foo: pass obj = foo() obj.bar = "I thought Python was strongly typed?" print(obj.bar) And even better: class foo: a = 42 obj = foo() print(obj.a) del foo.a print(obj.a) Whatever your opinion on what the imprecise sentence "strongly typed language" should mean, these are definitely not features of one.
- JoshCole 4y ago
  Yes, I can guess what the code does. But can you guess what this code will do? 1 + "1" Contrast Python (a strongly typed language): >>> 1 + "1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' >>> [] + 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "int") to list With Javascript (a weakly typed language): 1 + "1" "11" [] + 1 "1"
  - tsimionescu 4y ago
    JS's typing is weaker than Python's, but Python still has a relatively weak type system - particularly in old-style classes as GP was showing (class foo(object)-style classes fix those problems, or at least some of them) EDIT: I was wrong about new-style classes fixing this. Other dynamic languages are stronger than both - for example Common Lisp.
    - filmor 4y ago
      There are no old-style classes in Python 3.
      - tsimionescu 4y ago
        Oops, you're right, and the problem isn't fixed by new-style classes. I must have misremembered something.
  - dehrmann 4y ago
    > 1 + "1" Did someone say PHP?
    - withinboredom 4y ago
      PHP has a strict mode.
  - masklinn 4y ago
    > With Javascript (a weakly typed language): I'm always wary of these, because you can define that as strongly typed if it's the operation which is defined to perform the conversion internally, which IIRC is how it works in javascript. For instance the first example will do the exact same thing in Java, because addition between a string and a non-string is defined as converting the non-string to a string then concatenating. The second operation is not defined such in Java, but in theory you could have a universal toNumber protocol and define the addition of a non-integer and an integer as converting the non-number to a number then adding.
    - Izkata 4y ago
      > which IIRC is how it works in javascript. Yes, when objects are involved it's internally translated to: ([]).toString() + 1 This can be shown by changing the default implementation: > Array.prototype.toString = function() { return 'Boo!'; } > [] + 1; "Boo!1" Changing the prototype for Number doesn't work so I assume there's something slightly different going on there.
      - masklinn 4y ago
        > Changing the prototype for Number doesn't work so I assume there's something slightly different going on there. The answer is that addition first checks if either operand has a "primitive value" which is string-typed, if so it's a string concatenation, otherwise it's a numerical addition, at which point it converts both operands to numbers and adds them. The primitive value of a `Number` is a `number`, so changing `Number.prototype.toString` has no effect (it's not even called). However if you set `Number.prototype[Symbol.toPrimitive]` then you can influence the rest of the process. Still won't affect an addition of primitive `number` values but: > Number.prototype[Symbol.toPrimitive] = function(hint) { return String(this.valueOf()) } > new Number(4) + 2 < "42" > 4 + new Number(2) < "42" [numeric binops]: https://262.ecma-international.org/13.0/#sec-applystringornumericbinaryoperator https://262.ecma-international.org/13.0/#sec-applystringornu... [numeric conversion]: https://262.ecma-international.org/13.0/#sec-tonumeric https://262.ecma-international.org/13.0/#sec-tonumeric
    - 4y ago
  - bzxcvbn 4y ago
    So your bar for strong typing is that some type conversions are not made implicitly. That's a pretty low bar.
    - JoshCole 4y ago
      I consulted Wikipedia and other sources and placed the term they used to categorize these languages beside the language name; it wasn't my bar - I use the collection of symbols I use in the positions I use because others chose to do so. I shared the trivial creation of type errors in Python to help you notice why others oppose your definition and wish you to adopt more precise terms. I don't disagree with you that there is imprecision - comparative language is always with respect to a reference and without a reference specification it is meaningless. The deeper point is that you can't complain about imprecision while failing to do contrast. It would be like complaining that weight 100 doesn't tell you whether someone has a weight. Of course it doesn't. Units needs to be included for measures for them to meaningful. That doesn't mean the concept of units is unsound. It means you need to specify weight more thoroughly to avoid ambiguity. Really think about what you said and it compiles to something akin to: type_strength(sample(python_programs, size=1, heuristic=representative_of_claim)) < undefined In contrast my statement compiles to something like: type_strength(sample(python_program, size=2, heuristic=represenative_of_claim_simple_programs_first) > type_strength(sample(javascript_program, size=2, heuristic=represenative_of_claim_simple_programs_first)) There are a bunch of problems with my approach. We can pick it apart endlessly. It is positivism. It is low sample size. The heuristic is biased. That I reported it was subject to bias. `type_strength` isn't well defined. Neither is `>`. It is terrible in so many respects.
- Too 4y ago
  No need to guess, IDE is flashing bright red and mypy screaming main.py:5: error: "foo" has no attribute "bar". One could still say fuckit and run it anyway, but why would you take that risk. This would never get through to production.
  - bzxcvbn 4y ago
    It's not your IDE's features that determine if the language is strongly typed or not.
bogdanoff_2 4y ago
Well, it's not very strongly typed if you use dicts with default values for everything.

FWIW “strong” typing is a colloquial term and lacks any precise meaning.

Can you guess what this code does? class foo: pass obj = foo() obj.bar = "I thought Python was strongly typed?" print(obj.bar) And even better: class foo: a = 42 obj = foo() print(obj.a) del foo.a print(obj.a) Whatever your opinion on what the imprecise sentence "strongly typed language" should mean, these are definitely not features of one.

JoshCole 4y ago
Yes, I can guess what the code does. But can you guess what this code will do? 1 + "1" Contrast Python (a strongly typed language): >>> 1 + "1" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' >>> [] + 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "int") to list With Javascript (a weakly typed language): 1 + "1" "11" [] + 1 "1"
- tsimionescu 4y ago
  JS's typing is weaker than Python's, but Python still has a relatively weak type system - particularly in old-style classes as GP was showing (class foo(object)-style classes fix those problems, or at least some of them) EDIT: I was wrong about new-style classes fixing this. Other dynamic languages are stronger than both - for example Common Lisp.
  - filmor 4y ago
    There are no old-style classes in Python 3.
    - tsimionescu 4y ago
      Oops, you're right, and the problem isn't fixed by new-style classes. I must have misremembered something.
- dehrmann 4y ago
  > 1 + "1" Did someone say PHP?
  - withinboredom 4y ago
    PHP has a strict mode.
- masklinn 4y ago
  > With Javascript (a weakly typed language): I'm always wary of these, because you can define that as strongly typed if it's the operation which is defined to perform the conversion internally, which IIRC is how it works in javascript. For instance the first example will do the exact same thing in Java, because addition between a string and a non-string is defined as converting the non-string to a string then concatenating. The second operation is not defined such in Java, but in theory you could have a universal toNumber protocol and define the addition of a non-integer and an integer as converting the non-number to a number then adding.
  - Izkata 4y ago
    > which IIRC is how it works in javascript. Yes, when objects are involved it's internally translated to: ([]).toString() + 1 This can be shown by changing the default implementation: > Array.prototype.toString = function() { return 'Boo!'; } > [] + 1; "Boo!1" Changing the prototype for Number doesn't work so I assume there's something slightly different going on there.
    - masklinn 4y ago
      > Changing the prototype for Number doesn't work so I assume there's something slightly different going on there. The answer is that addition first checks if either operand has a "primitive value" which is string-typed, if so it's a string concatenation, otherwise it's a numerical addition, at which point it converts both operands to numbers and adds them. The primitive value of a `Number` is a `number`, so changing `Number.prototype.toString` has no effect (it's not even called). However if you set `Number.prototype[Symbol.toPrimitive]` then you can influence the rest of the process. Still won't affect an addition of primitive `number` values but: > Number.prototype[Symbol.toPrimitive] = function(hint) { return String(this.valueOf()) } > new Number(4) + 2 < "42" > 4 + new Number(2) < "42" [numeric binops]: https://262.ecma-international.org/13.0/#sec-applystringornumericbinaryoperator https://262.ecma-international.org/13.0/#sec-applystringornu... [numeric conversion]: https://262.ecma-international.org/13.0/#sec-tonumeric https://262.ecma-international.org/13.0/#sec-tonumeric
  - 4y ago
- bzxcvbn 4y ago
  So your bar for strong typing is that some type conversions are not made implicitly. That's a pretty low bar.
  - JoshCole 4y ago
    I consulted Wikipedia and other sources and placed the term they used to categorize these languages beside the language name; it wasn't my bar - I use the collection of symbols I use in the positions I use because others chose to do so. I shared the trivial creation of type errors in Python to help you notice why others oppose your definition and wish you to adopt more precise terms. I don't disagree with you that there is imprecision - comparative language is always with respect to a reference and without a reference specification it is meaningless. The deeper point is that you can't complain about imprecision while failing to do contrast. It would be like complaining that weight 100 doesn't tell you whether someone has a weight. Of course it doesn't. Units needs to be included for measures for them to meaningful. That doesn't mean the concept of units is unsound. It means you need to specify weight more thoroughly to avoid ambiguity. Really think about what you said and it compiles to something akin to: type_strength(sample(python_programs, size=1, heuristic=representative_of_claim)) < undefined In contrast my statement compiles to something like: type_strength(sample(python_program, size=2, heuristic=represenative_of_claim_simple_programs_first) > type_strength(sample(javascript_program, size=2, heuristic=represenative_of_claim_simple_programs_first)) There are a bunch of problems with my approach. We can pick it apart endlessly. It is positivism. It is low sample size. The heuristic is biased. That I reported it was subject to bias. `type_strength` isn't well defined. Neither is `>`. It is terrible in so many respects.
Too 4y ago
No need to guess, IDE is flashing bright red and mypy screaming main.py:5: error: "foo" has no attribute "bar". One could still say fuckit and run it anyway, but why would you take that risk. This would never get through to production.
- bzxcvbn 4y ago
  It's not your IDE's features that determine if the language is strongly typed or not.

bogdanoff_2 4y ago

Well, it's not very strongly typed if you use dicts with default values for everything.