Why static typed languages are sometimes better.

[Roy Smith]

I just had an interesting little surprise. I've got a method that takes
a string as an argument. I wanted to change it to take either a string
or a tuple of strings, so I did my usual "test first" thing.

I changed the unit test I already had from calling it with a string to
calling it with tuple of two strings. I then ran the test, expecting it
to fail. The next step would be to go write the code to make the test
pass.

Amazingly, the test passed (that means I'm done, right?). Well, it took
me a moment to realize that the only thing I ever do with the argument
in the current version is use it as a dictionary key. Since a tuple of
two strings is a valid key, so the test passed just fine. Sometimes the
language is just too forgiving

 

[Wai Yip Tung]

I agree. I appreciate the dynamic and polymorphic power of Python. On the
other hand I hope it does a better job to catch my silly mistakes and
typos. If only there is something like a lint it would save me something
fixing runtime errors.

Wai Yip Tung

 

[Donn Cave]

I just had an interesting little surprise. I've got a method that takes
a string as an argument. I wanted to change it to take either a string
or a tuple of strings, so I did my usual "test first" thing.

I changed the unit test I already had from calling it with a string to
calling it with tuple of two strings. I then ran the test, expecting it
to fail. The next step would be to go write the code to make the test
pass.

Amazingly, the test passed (that means I'm done, right?). Well, it took
me a moment to realize that the only thing I ever do with the argument
in the current version is use it as a dictionary key. Since a tuple of
two strings is a valid key, so the test passed just fine. Sometimes the
language is just too forgiving

Static typing might also have the salutory effect of
helping you decide not to do this in the first place.

You'd change the function parameter type from String
to [String], and recompile. The compiler would tell
you about every place where the function is called
with a String parameter, and you'd go and change them
from 'xyz "Hello"' to 'xyz ["Hello"]'. Takes 10 minutes
and leaves you with simpler, easier to understand code.

Donn Cave, (e-mail address removed)

 

[Lothar Scholz]

I agree. I appreciate the dynamic and polymorphic power of Python. On the
other hand I hope it does a better job to catch my silly mistakes and
typos. If only there is something like a lint it would save me something
fixing runtime errors.

There was a lint: PyChecker.
But for unkown reasons it is now dead.
And we still have no tools that makes use of manually added type
declarations.

 

[Steven Rumbalski]

There was a lint: PyChecker.
But for unkown reasons it is now dead.

Pychecker was updated 6 june 2004. Doesn't look dead to me!

 

[Mike Austin]

I just had an interesting little surprise. I've got a method that takes
a string as an argument. I wanted to change it to take either a string
or a tuple of strings, so I did my usual "test first" thing.

I changed the unit test I already had from calling it with a string to
calling it with tuple of two strings. I then ran the test, expecting it
to fail. The next step would be to go write the code to make the test
pass.

Amazingly, the test passed (that means I'm done, right?). Well, it took
me a moment to realize that the only thing I ever do with the argument
in the current version is use it as a dictionary key. Since a tuple of
two strings is a valid key, so the test passed just fine. Sometimes the
language is just too forgiving

There are dynamically typed language such as Dylan and CLOS that can put
restrictions on what type of arguments are passed to functions, and fail if
there is no match. Although this is using a mechanism -- multimethods. On
that thought, are multimethods considered to be a form of type checking, or
simply a mechanism? Hmm.

Mike Austin

 

[David Bolen]

Amazingly, the test passed (that means I'm done, right?). Well, it took
me a moment to realize that the only thing I ever do with the argument
in the current version is use it as a dictionary key. (...)

Note that independent of the static v. dynamic question, to answer
your question, no, the test passing doesn't mean you're done - at
least not if you're following a TDD approach. In TDD, the first step
is to write a _failing_ test. If the test you write doesn't initially
fail, that's a red flag that should be examined. Now, it may turn out
the test is ok, the code is in fact ok, or even that the new test is
superfluous. But it also may mean that the test is incomplete or that
it exposes something the code was previously doing that needs
adjusting.

In this case, if the only code that ever accessed the key to the
dictionary was your routine that was passing the new test, you may in
fact be done, since just storing the tuple in the dictionary still
satisfies your tests. Conversely if the tuple should result in
distinct dictionary entries, then presumably that's what your test
should be validating, so something may be missing from the test to
enforce the desired behavior.

In any event, the lack of a failure should immediately make you study
the situation, as you obviously did, and figure out just what is going
on.

-- David

 

[George Sakkis]

Now is this a coincidence or what ? Just a few days ago I posted a
very similar typing accident I had. This made me write a simple
runtime type checking module, which would presumably be useful to
prevent such pitfalls. I'm not sure though if it adds up much to the
simple isinstance() assertions. Here's the original post:

http://groups.google.com/groups?hl=...7010856480.31307-100000%40ccc1.wpi.edu&rnum=1

 

[Kerim Borchaev]

Hello Roy,

Friday, July 2, 2004, 1:43:56 AM, you wrote:

RS> so the test passed just fine.
If tests pass after a refactoring asume that code works.
Or add a failing test.

Best regards,
Kerim mailto:[email protected]

 

[Ville Vainio]

Mike> There are dynamically typed language such as Dylan and CLOS
Mike> that can put restrictions on what type of arguments are
Mike> passed to functions, and fail if there is no match.
Mike> Although this is using a mechanism -- multimethods. On

Common Lisp supports optional type declarations also without
CLOS/multimethod mechanism. Type declarations are used to improve
performance of the compiled code.

Guido has said (Nokia "Python for S60" workshop in June) that Python
will also have such declarations at some point in time.

Mike> that thought, are multimethods considered to be a form of
Mike> type checking, or simply a mechanism? Hmm.

Multimethods (as a runtime mechanism) can be used in Python too,
multiple solutions have been presented on the net.

 

[Heather Coppersmith]

There are dynamically typed language such as Dylan and CLOS that
can put restrictions on what type of arguments are passed to
functions, and fail if there is no match. Although this is
using a mechanism -- multimethods. On that thought, are
multimethods considered to be a form of type checking, or simply
a mechanism? Hmm.

Is "Object Oriented Programming" a form of type checking, or
simply a mechanism?

Untested code:

class A:
def a( self ): print "A.a"

class B:
def a( self ): pass "B.a"

class C:
pass

def foo( an_object ):
an_object.a( )

foo( A( ) )
foo( B( ) )
foo( C( ) )

For that matter, what about imperative programming and simple
binary operators?

print "a" / 4.0

Previous pythons raised exceptions for this:

print 2**24 * 2**24

Somewhere along the line, you must meet some minimum criteria for
using any given mechanism, and the mechanism itself may contain
"checking" of one kind or another. If I load two CPU floating
point registers with "random garbage" (whatever that means) and
then try to multiply them together, but the CPU throws a floating
point exception, is that type checking?

Regards,
Heather

 

[Roy Smith]

Note that independent of the static v. dynamic question, to answer
your question, no, the test passing doesn't mean you're done - at
least not if you're following a TDD approach.

Yes, I know that. It wasn't so much a question as a satirical comment

 

[David Bolen]

Yes, I know that. It wasn't so much a question as a satirical comment

Ah, so that Whoosh! I heard in the background was that fact going
right over my head at 4am in the morning ... drat.

Ah well, I'll just consider it a few bytes for the archives for any
others who may have had the same blind spot.

-- David