Adding static typing to Python

[Jim Dennis]

In article <24c39b2c.0202181531.187fad4c at posting.google.com>, 
Alexander Jerusalem wrote:

> Has anyone heard of plans to add static type checking to Python? I
> like Python very much but I don't use it for bigger projects because I
> fear the testing effort. For example I just refactored a rather large
> Java codebase. And when I change a method name for example, all I have
> to do is run everything thru the compiler and it will show me all
> places in other classes where this method is called, so I can go there
> and chenge the method call as well.

> In Python I'd have to test the whole software suite including each and
> every branch in each and every if statement to be sure that I didn't
> forget something. To build such a test suite would take almost as long
> as it takes to build the whole software and I'd have to maintain the
> test suite as well. That's just unafordable.

> On the other hand, Python is the best language that currently exists
> and I would like to use it on bigger projects not just for prototyping
> as some suggest.

> Regards,
> Alexander Jerusalem

 Let's think about this suggestion:  static typing allows you to use
 one technique for detecting a particular programming oversight
 in one particular (family of) programming languages (by raising compile 
 time errors).  So this "feature" (or constraint or put most neutrally,
 "characteristic")  must be available in all other languages so that
 you can use the same technique.

 Perhaps you should consider using a different technique.  Is there
 another technique that might detect the sorts of errors you're 
 looking for?  Maybe you should consider adding additional tools to 
 your toolbox?

 For example, you might look at PyChecker.  It might do what you 
 want, or you might extend it to do what you want.  Python has 
 wonderful "metaprogramming" (introspection/reflection) features
 (using .__class__ and .__dict__ etc).  So you could write or 
 modify a tool to walk through your modules, class trees, and their
 members and methods and report on all sorts of errors.  

 Of course there are limitations to this technique.  For example
 I see that it's common for Pythonistas to use raise NotImplementedError
 for abstract classes.  It would be nice of PyChecker could detect
 any time a concrete subclass fails to implement any of the requisite
 abstract functions.  Of course it's difficult to see how this would
 be accomplished given current language features: how would we tell
 that a given abstract function is "abstract" (is defined to raise 
 NotImplementedError)? how could we tell that a given subclass was
 "concrete" (final)?  (Obviously we can see that any class that is
 used to instantiate an object must be concrete, though not necessarily
 "final", but that only works if we're given a whole project, otherwise
 there might be classes which are intended to be concrete but not
 used within the scope of our hypothetical scanning engine)
 
 However, this all begs the original question.  You're using the 
 compiler as a "test" tool.  Historically we see that compilers make
 very poor test suites.  There's just too many bad bits of code that
 compile.

 So perhaps it's better to go back to basics: 

	Requirement:  	You need rapid feedback from 
			programming errors in large projects
			(for refactoring and enhancement)

 ... so you want automated tests that will alert you when changes
 in your project's modules, classes, packages, and other structures
 "breaks stuff."

 So, build them in as part of the development process.  Mark Pilgrim's
 "Dive Into Python" (http://www.diveintopython.org/) has a whole
 chapter on unit testing (and extensive examples of using the unittest
 modules for Python).

 Then you'll be testing for far more then just superficial syntactical 
 errors; you should catch semantic errors more quickly.  Every time
 one "slips through" try to figure out ways to add cases to the appropriate
 test suite(s).