1) It's meaningless--it's almost impossible to produce a real ranking of languages on the strength of their types.
2) These dynamic languages are all unityped because they're not statically typed. The fact that runtime tags won't allow certain operations to succeed has nothing to do with types.
3) Strongly typed is a rough and ready way of saying you don't do many implicit conversions.
I sympathize with (1). (2) is accurate, but really a terminological point. There's clearly a phenomenon to talk about, even if "typed" is the wrong word. I also sympathize with (3).
Python does far fewer implicit conversions than PHP, JavaScript or Perl. It even doesn't do at least one that Java does. So people often say Python is strongly, but dynamically typed. It's a real aspect of the language that you can view as a plus or minus.
>>> 1 + "0"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
In [1]: 1 + 2.5
Out[1]: 3.5
In [2]: "foo" * 3
Out[2]: 'foofoofoo'
In [3]: [1, 2] * 3
Out[3]: [1, 2, 1, 2, 1, 2] In [1]: "foo" + 3
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-1-21582e79f06e> in <module>()
----> 1 "foo" + 3
TypeError: cannot concatenate 'str' and 'int' objects
In a way it is kind of funny to call it, "strongly typed," but it does work. Maybe it should be called, "instancely-typed."
It seems to make 'strongly typed' pretty meaningless, and this definition is probably _not_ what anyone who says they want a "strongly typed" langauge is using, so it hardly counters them to say that python is "strongly typed" under another definition, it's just confusing them with semantics.
(Of course, the people who say they want 'strongly typed' may have no idea what they're actually talking about, but wouldn't it be better to educate them then to take advantage of their ignorance to push your pro-python agenda?)
In general, when someone is talking about strong typing, they are talking about silent failure for unintuitive or ambiguous constructs. For example, if the expression
x = '1' + 1
x = 32;
x = '11'
x = 2
You could also describe Python's type system to be dynamic in that instances of the type meta-class define the constraints and objects (instances of a class) can have constraints added and removed at run-time. Python is still fairly strong in this regard in that the built-in classes are immutable (ie: it is a TypeError to assign a bound method to an attribute on a built-in class such as str).
I suggest "instancely-typed" because categories, unions, and type theory. I'm only coming to grips with that in that OCaml's type solver can be both awesome, annoying, and cryptic. And at the end of the day I'm still not sure what it's buying me other than proving exhaustive pattern matches in certain conditions, fast pattern dispatching, and requiring specialized operators (+, -, , / for ints... +.,-.,.,/. for floats... etc). I'm sure the enlightenment will come when it stops becoming such a PITA to write a basic program.
Sometimes not having to satisfy the constraints up-front makes exploratory programming (where the constraints are not specified and known up front) easier. Python is going the annotation route in newer versions of the language which is rather useful so that tools could be written to verify consistency up-front (or at least provide hints).
Otherwise, you'd run into Python's strong type system when doing an incompatible operation.
The interpreter/type system is doing nothing implicitly behind the scenes to coerce the objects.
I particularly like Python's arbitrary-precision integers, where ints are implicitly converted to longs, allowing you to have the performance of ints without the problem of integer overflows.
I think the reality is "strongly typed" doesn't really mean much.
As most OO languages, Python has function overloading based on the type of the parameters. The fact that those operators do different things when operating on different types is evidence that Python has strict types, not loose.
There is no dynamic dispatch based on types in the interpreter, you have to manually do it in the body of the method, of which you have one.
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/2.3
0.4347826086956522
>>> 1 / 2.3
fish: Job 2, 'python' terminated by signal SIGSEGV (Address boundary error)
Python 2.7.5 (default, Nov 3 2014, 14:26:24)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/2.3
0.4347826086956522
>>> 1 / 2.3
0.4347826086956522
Yep -- it seems like a readline problem. As you can tell, I don't use this machine for Python.
There are many popular and weakly typed languages in use today.
"[object Object]"
> {} + []
0
JS and PHP are the prototypical examples of weak typing.
Languages are often colloquially referred to as "strongly typed" or "weakly typed". In fact, there is no universally accepted definition of what these terms mean. In general, there are more precise terms to represent the differences between type systems that lead people to call them "strong" or "weak".
Static typing would be nice, but not in a Java or C# or C++ way. The extra verbosity makes it not worth the benefits. Sure, you get slightly more reliable intellisense, but at the expense of a program that's 15-20% longer.
These two statements conflict.
But I think he overstates the case.
Calling Python "compiled" doesn't seem right -- he's more right that this doesn't matter, there's no reason not to use something because it's "not compiled".
Calling Python's typing "strong typing", eh, really? He provide a link to a wikipedia article on typing in general, how about a link to anyone else making the case that Python should be considered 'strongly typed', for a particular definition of 'strongly typed'? I'm dubious that it would be any definition of 'strongly typed' that those who think they want it... want. Again, I think a better argument might be: So what, you don't need strong typing for success, because of a b and c.
And the concurrency discussions is just silly. Sure, you can do _all sorts_ of things without multi-core concurrency, you may not need it or even benefit from it, and scaling to multi-process can sometimes work just fine too. But there are also _all sorts_ of cases where you do really want multi-core parallelism, and Python really doesn't have it -- and trying to justify this as "makes it much easier to use OS threads" is just silly. I guess it makes it 'easier' in that it protects you from some but not all race conditions in fairly unpredictable ways -- but only by eliminating half the conceptual use cases for threads in the first place (still good for IO-bound work, no longer good for CPU-bound work).
I think there's a reasonable argument to be made that Python will work just fine for 'enterprise' work. There are also, surely, like for all languages/platforms, cases where it would be unsuitable. By overstating the case with some half-truths and confusions, he just sounds like a fanboy and does not help increase understanding or accurate decision-making -- or confidence in the Python community's understanding!