Python vs .Net

Greg Brunet gbrunet at nospamsempersoft.com
Tue Jan 7 23:46:42 EST 2003


"Bjorn Pettersen" <BPettersen at NAREX.com> wrote in message
news:mailman.1041878711.16028.python-list at python.org...

I think you're missing the point of dynamic typing. In a dynamically
typed language I can write a function, add, like:

  def add(a,b):
      return a + b

the result is to create a function that can operate on _any_ type of
objects that support the '+' operator. There is usually a strong urge
from programmers coming from statically typed languages to want to add
type information to this function or add run-time checks to ensure
they're only passed the right kind of data. In a dynamically typed
language this is at best counter productive and at worst simply wrong.

<snip... more good stuff>
========================

Hi Bjorn:

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.

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?

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?

It seems that someplace, somewhere, the language needs to decide what
Add(a,b) [or a+b] is going to do for all variations of types.  If I have
a line with result = someString + someInteger, then with a statically
typed language, I'll (optionally) know about it at compile time as well
as at runtime (if I turn off the compile checking), but you won't know
about it till runtime.

I've admitted to working on thinking Pythonically - I know I'm not there
yet.  Your comment about writing Fortran in any language was apropos.
Even though I did manage to stop writing Fortran when I had to write
RPG,  I'm probably a little slow in adapting to a new language, since I
tend to still think in terms of what I'm already familiar with.

--
Greg






More information about the Python-list mailing list