“Strongly typed” is meaningless. (Or nearly so; in practice it means “I like this language” and “weakly typed” means “I dislike this language”.) The point is that Python has no type system.
There absolutely is a type system in Python. The fact that you have dynamic types doesn’t preclude having also strong types and certainly doesn’t mean you don’t have types at all.
Try to do 2+“a” in Python and you’ll get a TypeError.
The thing with Python is that values have a type, not variables. Because all variables are essentially pointers.
But from a type theory perspective, having “dynamic types” absolutely means you don’t have a type system. All Python has is runtime exceptions. The fact that one of them is named TypeError doesn’t make it a type error in the formal sense.
The point of a type system is not that variables have types, but that types are assigned to expressions (i.e. pieces of code in your source file), not to values (i.e. pieces of data). This is important because it guarantees that certain errors cannot occur in a program that passes the type checker (assuming you have a sensible/useful type system). And you get this assurance without running a single line of code.
To get a similar guarantee from Python, you need to write exhaustive tests, just as with any other runtime error.
That’s a very narrow definition of limited usefulness, and in practice it means your code is overly verbose and inflexible. You get stuck with polymorphism everywhere or you’re explicitly converting data all the time for nothing.
Plus, if you try to process some data from an external source (which you have to if you want to do anything useful) you don’t have any way to test if it’s the right type before execution, so you’re back at the same place that Python is, without the ability to cleanly recover.
I believe now it is my turn to say you’re spewing nonsense. Have you ever used a language with a type system? Because this whole idea of “testing external data to see if it is the right type” doesn’t really make sense.
At the lowest layer, generally, external data is an array of bytes. It has no other type you could “test”. However, you can decode or parse it into a form that makes sense for your program. And why couldn’t I cleanly recover from parse errors? (And how do you think Python does it?)
Python. Don’t know why you excluded it.
I didn’t, I’m using the current nomenclature: https://en.wikipedia.org/wiki/Python_(programming_language)#History (last paragraph)
I don’t see the image and the last paragraph sais nothing about types.
But Python is a strongly typed language. It’s right there in the info box.
Python is un(i)typed.
It’s not. It’s a strongly typed langage.
“Strongly typed” is meaningless. (Or nearly so; in practice it means “I like this language” and “weakly typed” means “I dislike this language”.) The point is that Python has no type system.
You’re spewing nonsense.
There absolutely is a type system in Python. The fact that you have dynamic types doesn’t preclude having also strong types and certainly doesn’t mean you don’t have types at all. Try to do 2+“a” in Python and you’ll get a TypeError. The thing with Python is that values have a type, not variables. Because all variables are essentially pointers.
Again, “strong types” doesn’t mean anything.
But from a type theory perspective, having “dynamic types” absolutely means you don’t have a type system. All Python has is runtime exceptions. The fact that one of them is named
TypeErrordoesn’t make it a type error in the formal sense.The point of a type system is not that variables have types, but that types are assigned to expressions (i.e. pieces of code in your source file), not to values (i.e. pieces of data). This is important because it guarantees that certain errors cannot occur in a program that passes the type checker (assuming you have a sensible/useful type system). And you get this assurance without running a single line of code.
To get a similar guarantee from Python, you need to write exhaustive tests, just as with any other runtime error.
That’s a very narrow definition of limited usefulness, and in practice it means your code is overly verbose and inflexible. You get stuck with polymorphism everywhere or you’re explicitly converting data all the time for nothing.
Plus, if you try to process some data from an external source (which you have to if you want to do anything useful) you don’t have any way to test if it’s the right type before execution, so you’re back at the same place that Python is, without the ability to cleanly recover.
I believe now it is my turn to say you’re spewing nonsense. Have you ever used a language with a type system? Because this whole idea of “testing external data to see if it is the right type” doesn’t really make sense.
At the lowest layer, generally, external data is an array of bytes. It has no other type you could “test”. However, you can decode or parse it into a form that makes sense for your program. And why couldn’t I cleanly recover from parse errors? (And how do you think Python does it?)
Clearly you’ve never programmed anything outside of theoretical computer science or heavily enclosed and controlled systems.