It's not contrary, it's just convenience. One of the weaknesses in Python (if you can call it that) is that everything is an "object." The classes implementing string, list, and integer simply have methods that respond to those operators and rhs types.

  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

That's because the "special" method "__add__" implemented by the string class will raise TypeError if it gets any object that isn't an instance of a subclass of string.

In a way it is kind of funny to call it, "strongly typed," but it does work. Maybe it should be called, "instancely-typed."

Okay, with this definition of 'strongly typed', can anyone come up with an example language that _isn't_ strongly 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?)

C is not strongly typed.

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

results in an error, you are probably using a strongly-typed language. In C, this is equivalent to

    x = 32;

In javascript you get

    x = '11'

In PHP you get

    x = 2

These are examples of weak typing.

Strong, as opposed to weak, implying that there is type-constraint checking; it's just done at run-time in Python.

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).

Javascript comes to mind, since it only functionally has I think 5 types (string, number, boolean, array, object - and the line between array and object is blurry) and no user-added ones. There are no built-in type semantics whatsoever other than what properties are present on an object at the time of its use. Functions of different arities aren't even type-differentiable (although arity is available as a reflectable value).

I don't know. Runtime type checking is necessary because the language doesn't have constructs which allow dispatching based on type.

Otherwise, you'd run into Python's strong type system when doing an incompatible operation.

No. That would be evidence of polymorphism. Those objects have explicit ways of handling those operations based on the types or interface of the object left/right of the operand.

The interpreter/type system is doing nothing implicitly behind the scenes to coerce the objects.

I love Python for things like this. 'foo' * 3 is so intuitive. Seriously, to hell with Java's StringWriters and StringBuffers and StringBufferInputStream throws IOException.

This is a great example, which is why I think "strong vs. weak" typing is properly thought of as a scale rather than a classification. Which is used properly in the blog post, merely comparing some instances of implicit conversion in JVM that make less sense by default (all of your examples can be argued to be deliberately useful, as opposed to Javascript WAT-style statements).

I agree with your second point. Python doesn't pretend to be strongly-typed, but it does use its, uh, 'loose' typing to great advantage.

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.

You say "python doesn't pretend to be strongly-typed", yet the OP is claiming it _is_ strongly typed.

I think the reality is "strongly typed" doesn't really mean much.

No. Why would it?

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.

Not overloading in the sense of Java and what not.

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.