What is a "type", anyway?

Before talking about what kind of type system a language supports, we should establish agreement about what a type is in the first place. My definition is that a type is metadata about a chunk of memory that classifies the kind of data stored there. This classification usually implicitly specifies what kinds of operations may be performed on the data.

Common types include primitive types (strings and numbers), container types (lists/arrays and dictionaries/hashes), and user-defined types (classes). In Python, everything is an object, and every object has a type. In other words, functions, modules, and stack frames are also types.

So what's "strong typing", then?

From my POV, strong typing prevents mixing operations between mismatched types. In order to mix types, you must use an explicit conversion. Here's a simple Python example:

>>> 1 + "1"
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>> 1 + 1
2
>>> "1" + "1"
'11'
>>> 1 + int("1")
2
>>> "1" + str(1)
'11'

Conversely, weak typing means that you can mix types without an explicit conversion. Consider this example from Perl:

  DB<1> print "1"+1
2
  DB<2> print "1".1
11

Note that conversion is not the same thing as coercion, IMO. Coercion occurs when you have a statically-typed language and you use the syntactic features of the language to force the usage of one type as if it were a different type (consider the common use of void* in C). Coercion is usually a symptom of weak typing. Conversion, OTOH, creates a brand-new object of the appropriate type.

Why do some people think Python has weak typing?

Historically, "strong typing" has been associated with static typing. Languages noted for strong typing include Pascal and Ada; languages noted for weak typing (most notoriously BASIC) had primarily dynamic typing. But the language that ought to be most notorious for weak typing has static typing: C/C++ (yes, I'm lumping them together)

It's very clear that Python has only dynamic typing; any target may hold a binding to any kind of object. More than that, Pythonic programming style is to use inheritance primarily for implementation; Python's name-based polymorphism means that you rarely need to inherit for interface. In fact, the primary exception to inheriting for implementation is Python exceptions, which uses issubclass() for the purpose of determining which exceptions get caught by an except clause.

I might even go so far as to say that Python's name-based polymorphism is hyperpolymorphic. And therein lies the tiny kernel of truth about Python's weak typing. People who have gotten used to Java and C++ requiring syntactic support to declare typing often feel uncomfortable with the Pythonic style of relying on run-time exceptions to get thrown when an inappropriate object is passed around:

class Silly:
    def __init__(self, data):
        self.data = data
    def __add__(self, other):
        return str(self.data) + str(other.data)

def double(a):
    return a + a

print double(1)
print double('x')
print double([1])
print double(Silly({'a':1}))
print double({'a':1})

2
xx
[1, 1]
{'a': 1}{'a': 1}
Traceback (most recent call last):
  File "test.py", line 14, in ?
    print double({'a':1})
  File "test.py", line 8, in double
    return a + a
TypeError: unsupported operand types for +: 'dict' and 'dict'

Bruce Eckel equates "weak typing" with "latent typing", but that's at odds with historical usage, not to mention that it confuses the two axes of strong/weak and static/dynamic.

Sidebar: Name-based polymorphism

For those of you unfamiliar with Python, here's a quick intro to name-based polymorphism. Python objects have an internal dictionary that contains a string for every attribute and method. When you access an attribute or method in Python code, Python simply looks up the string in the dict. Therefore, if what you want is a class that works like a file, you don't need to inherit from file, you just create a class that has the file methods that are needed.

Python also defines a bunch of special methods that get called by the appropriate syntax. For example, a+b is equivalent to a.__add__(b). There are a few places in Python's internals where it directly manipulates built-in objects, but name-based polymorphism works as you expect about 98% of the time.

Resources

Discussions of types

TUNES : Type System
http://cliki.tunes.org/Type%20System

type from FOLDOC
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?type

Python & Java: Side by Side Comparison
http://www.ferg.org/projects/python_java_side-by-side.html

Bruce Eckel and Python's weak typing

Artima Interview: Type Checking and Techie Control
http://www.artima.com/intv/typing.html

def communicate(anything):
  # ...
  anything.speak()
  # ...

class Pet:
  def speak(self): pass

class Dog(Pet):
  def speak(self): print "Arf!"

class Robot:
  def speak(self): print "Click!"

communicate(Dog())
communicate(Robot())

def communicate(anything):