Comment by kstrauser

> Strongly typed and weakly typed do not seem to have good definitions.

Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?

Note that Python supports type annotations in its syntax, but the interpreter will just ignore them as they are meant to be used by external tools such as ruff: https://github.com/astral-sh/ruff

I've had a good experience developing small to medium sized Python programs/scripts using type annotations plus ruff connected to my editor through its LSP (Language Server Protocol). It helps a lot, and I don't like to write Python without it.

You can create types from literal values and use union types, which I feel makes it more pleasant than Go's type system for example.

That's fair, and I don't claim that I have the canonically correct answers. My broader claim is that I don't think I've ever heard someone say ugh, I despise that my bucket of bytes has an associated type! The real discussions weren't against types, but against various type disciplines.

For example, I find it highly annoying to have to sprinkle type annotations all over the place when the compiler isn't smart enough to figure out what I mean, in the absence of ambiguity. Like imagine this C code:

  int main() {
      int i = 23;
      auto j = i;
      printf("i = %d, j = %d\n", i, j);
  }

There wasn't a great way until recently (C23, I think?) to say "just make j whatever type it needs to be here and don't pester me with it". Contrast with Rust which is strongly, statically typed but also infers types where it can:

  fn foo1() -> i8 {
      23
  }
  
  fn foo2() -> String {
      "foo2".into()
  }
  
  fn main() {
      let f1 = foo1();
      let f2 = foo2();
      let f3 = f1 + f2;
      println!("Hello, world!");
  }

Here, that bit in "foo2" says "cast this str into whatever type you can infer it's suppose to be". Since it's going to be the return value of a function that returns a String, it must be a String, so Rust casts it to a String. Similarly, the first line of main() says f1 is an i8 because it's assigned to something that returns an i8. f2's a String for the same reason. The f3 line is an error because you can't add an i8 and a String, and Rust can figure all that out without having to annotate f1 or f2.

I love Rust's typing because it's helpful and makes strong guarantees about the program's correctness. I'm not "anti-typing" at all. I'm just not a big fan of languages that make you annotate everything everywhere. Back when such arguments were in fashion, a pre-auto C fan might reduce my whole argument to "you don't like typing, newbie!", which would make me roll my eyes and hand them a lollipop.

FWIW, I think TypeScript's pretty great. I never like JS. I tolerated it, and could use it, but didn't enjoy it at all. TS is fun, though.

Python doesn't have variables in the C sense. It has pointers to objects (aka "names"), and the "=" is a pointer assignment operator.

So:

  i = 23  # Create an int(23) object and store its address in i
  i = "foo"  # Create a str("foo") object and store its address in i

i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't.

> Python's strong typing mostly boils down to some operator rejecting mixed types.

Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.

Strongly typed is not a well defined term.

But by most people definitions, Python certainly is NOT strongly typed.

My take at a definition... Strongly typed languages make a serious effort to use the type system to prevent whole categories of bugs.

It kinda bites with the "dynamic typing" (a euphemism or marketing-speak for "weak typing") that Python/Ruby/JS implement. Sure some are adding typing now (trying to make big codebases in those languages more manageable), but it's always an optional add-on.

That is what the parent author means. Static vs dynamic typing is along the dimension of when the type is checked, and strong vs weak typing is a matter of how strongly bound names adhere to types. JS, for instance, is super weak here, you can assign a numerical value to something and in the next line re-assign it to a string, an array, or even a function object.