> Python is considered a weakly-typed or dynamically-typed programming language. This isn't right. Weak/strong typing is on a different axis than static/dynami

> Python is considered a weakly-typed or dynamically-typed programming language. This isn't right. Weak/strong typing is on a different axis than static/dynamic typing. Python is strongly typed. There's no implicit conversion among types (which is one marker of weak-typedness). For proof, consider: >>> 1 + '3' [...] TypeError: unsupported operand type(s) for +: 'int' and 'str' Strongly typed means that the types are protective, in a way. You put a value in a box labeled X and that's it — you can only treat it as an X from now on. In a weakly-typed language, if your function expects an X and you give it a Y, well, it'll do its best to make due. Many people think that because Python is dynamically typed (i.e. you can pass anything anywhere without compile-time restrictions), that it must also be weakly typed. This is simply not the case. If I write a function which expects an integer and I give it a string, I'm going to have a bad time despite the fact that the code "compiles" and only fails at runtime. --- Edit: I've read further, and the author actually uses their lack of knowledge on this subject to portray the Python community as being willfully misleading in their promotion of the language: > Python markets itself as a dynamically-typed programming language, similar to Perl, Ruby, or JavaScript. The word “dynamically typed” has a positive connotation, more so than “weakly typed.” Conversely, the word “strongly typed” sounds more positive than saying “statically typed.” Diction matters, because proponents of different camps will select a word-choice that reflects their bias of one programming language over another. Python is both weakly-typed and dynamically typed, which contrasts itself to languages like Java, Scala, C/C++, and Go which are strongly-, statically-typed. C is statically typed, but it is also weakly typed. You can treat any value as any type if you so wish, either by explicitly casting or by removing checks for implicit casts during compilation. I'm going to finish reading this article, but... I don't think I respect this author very much, based on what I've seen so far. --- Edit 2: While the author's points would be valid by themselves (GIL, build toolchain, dynamic typing), the over-abundance of negative rhetoric shows that the author was merely interested in writing a smear article of Python, essentially. I think it's a pretty weak article overall, and would have been aided by a more fair comparison with notes about why some of these design decisions were made (or at least a less-slanted writing style).