Python vs .Net

[Brian Quinlan]

> I'm not always so good with the proper terminology, but it seems that
> what your talking about here (and what most folks also seem to be
> touting as the flexibility & advantage of dynamic typing) is
> overloading.  While I agree that overloading is a good thing, I'm not
> sure what this example really shows.  After all, the "+" operator is
> already overloaded, so all you're really doing here is providing a
> synonym for it.  Add does no more or less than what "+" already does.

Let's imagine a routine like this:

def matrix_rotate(matrix, angle, vector):
    "Rotate the specified matrix"
    from math import sin, cos

    ...

In Python, the matrix_rotate routine would likely work with a wide
variety of "matrix" types without any additional effort. In C#, you
would need to define a IMatrix interface and force all matrix arguments
to conform to that interface.
 
> Now regardless if we're talking about "+" or Add, I think that we can
> both agree on what to expect if both a & b are Integers or Strings.
> What if one is an integer & one is a string, however.  What if the
> string has a numeric value?  What if we have an Integer and a Float.

It makes mathematical sense for integers and reals to be addable because
the set of integers is a subset of the set of reals.

Strings and integers are quite unrelated.

> Older versions of VB suffered from what folks called "Evil Type
> Coercion".  It tried to do the 'right' thing, so that 5+"5" returned
10
> and 5 & "5" returned 55 (while 5+5=10 and "5"+"5"=55 as expected).
This
> was obviously a bad thing because it was inconsistent - better to be
> consistent.  OTOH, I see a bit of this even in Python with the change
in
> the division operator behavior (PEP 238) - should 5/2 return an
integer
> or a float?

VB was engaging in weak typing. Python is strongly typed. In Python you
can't get a string to act like an integer without an explicit cast.

Cheers,
Brian