Typing system vs. Java

[brueckd at tbye.com]

On 1 Aug 2001, Christopher Barber wrote:

> > > You have detected a bug at compile-time instead of run-time and you didn't
> > > have to write a unit-test to find it.
> >
> > Take off your Curl glasses for just a moment and think Pythonically - that
> > is an error only because of the language-specific constraints - in Python
> > it's neither an error nor a problem.

[snip]

> As to the error, this would indeed be an error in Python as well but it would
> happen later in the program when some code tries to use 'i' as an integer
> instead of a string.

This is exactly why this compile-time type checking is ill-suited for
Python. The error is _not_ at the time of the "assignment", but later.
*If* the error occurs it will happen when the program attempts to use that
value in an incorrect way. The difference between the two is quite
significant. In Python there really isn't any assignment per se, but the
creation and deletion of references to values. Variables don't have types,
the values do, and attempting to check the types of the variables makes
far less sense.

Putting all that aside and assuming that the programmer goes on to try and
use an integer value as a string in some unsupported way, will that error
hide any longer than the very first time that piece of code is executed?
Probably not. And when it rears its ugly head, how will it manifest
itself? As an exception that includes the line number of the error. And
since there's no explicit compile step in Python, I probably would find
and fix that problem in Python before the Java version's compiler even
finished compiling! <g> The issue at hand is whether strict compile-time
type checking adds enough value to warrant their inclusion - I don't see
significant savings here.

Again, I think this goes back (at least in part) to programming in Python
while using a C++/Java/whatever mindset. For example, if you don't check
for null in a C program, your program may die in bizarre ways, so it's a
common and good practice to always check for null pointers. When you move
to Java you'll bring with you the same tendency to always check them, but
very often this doesn't actually add much value (if you check and raise an
exception on null, this isn't much different than what the VM will do on
its own if you don't perform the check).

> > > The language does not force you to specify types, this would also be legal,
> > > but you would not see the problem until you actually executed the code:
> >
> > Again, it's a problem _created_ by the constraints of the language, and/or
> > the division of labor between the language and the programmer. It doesn't
> > apply here (since we're supposedly exploring the weaknesses that _Python_
> > has without strict compile-time type checking.
>
> I don't see why it doesn't apply.  If I am forced to do more work because
> Python doesn't do it for me, then why can't I consider that to be a weakness
> in the language?

Sure, *if* it forces you to do more work.

>      question about this fact.  You might not think the benefit is significant
>      enough to be worthwhile, but that is a different issue.

Uh, sorta. Maybe it's time for this thread to die, but for a little while
I thought we were judging cost vs benefits. If so, then magnitude of
cost/benefit is of utmost importance. I'll readily agree (again) that in
some cases there can exist some benefit for this kind of type checking,
but it also seems that this benefit is almost never significant in Python.

>   2) Static type declarations allow the programmer to clearly express
>      their intent.  In this role they are only a shade better than comments.

Right. My assertion is that this causes more problems than it solves
because you seldom know your "intent" in that much detail, much less your
future intent. Seems like ultra strict type checking might work well in
cases where you have very precise requirements and once built, your
software won't be changing any time soon (a la space shuttle software).
Most programs don't fall into that category.

> One problem I remember having was that I was writing library code and had to
> write explicit run-time type-checking code to check the types of incoming
> arguments.

But why? Anyone using the library would catch on pretty quickly if they
were passing in bogus values. Also, that sort of type-checking tends to
diminish the usefulness of the code (you allow someone to give you a
dictionary but you prohibit an object that looks and acts like a
dictionary). Once again, I can't help but feel that this is more a
misapplication of other-language-Best-Practices that don't necessarily fit
with Python than response to specific problems one encounters in
Python.

> BTW, is there a code coverage measurement tool for Python yet?

Tools/scripts/trace.py

-Dave