Python Scalability

[Graham Matthews]

Curtis Yanko (cmyanko at bigfoot.com) wrote:
: From a purely OO perspective, why are you breaking perfectly good
: classes instead of using inheritance? You either need a base class for
: this set of classes or you need to keep subclassing when you want to
: extend the interface.

The original poster is clearly asking for some kind of static type 
checking to ensure *at compile time* that his code does not try to 
access non-existent object fields. So far almost every answer in this
thread has simply dodged the question by criticising the original
posters code. 

I think there is a serious issue here that deserves some serious
thought. As I see it the issue is that Python does not provide
very good support for programming in the medium to large (yes
I know Python was designed as a scripting language but it is now
being used outside it's design areas). I personally stopped using
Python for anything beyond scripting because:

a) it does not provide any form of static typing, something I have
	 found to be essential on larger projects.
	 
b) it does't provide proper garbage collection (almost all my larger
	 Python apps leaked memory).
	 
c) I didn't really like any of the GUI toolkits/frameworks.

[note: I didn't mention speed -- Python is plenty fast enough for
most apps]

To give just one example. I wrote a GUI for a computer algebra system
using Python and Tk. This wasn't a really large program, but it
certainly wasn't a scrip either. I spent a good deal of my time
tracking down runtime typing errors, notably attribute exceptions.
Moreover the program leaked due to circular references. I then rewrote 
the system in TkGofer (a statically typed functional language). The 
static typing of Gofer proved tremendously helpful in finding errors b
efore I ran the code. And my code did not leak since Gofer has full
garbage collection.

I have come back to considering Python for large projects because of
JPython. It potentially address both b) and c). However a) is still
a very big issue. 

Some suggestions here are:

For a):
Allow the user to "declare" types and object fields. Write a tool that
uses these "declaration" to check Python code *as if* it were statically
typed. Ignore these type "declarations" when generating code so as to
retain the current semantics. "Declarations" don't have to be anything
more than stylised comments (just something that the tool can extract
easily). The tool will not provide a guarantee of type correctedness
(that is not possible in Python), but will provide programming support
for types. Moreover it will do all that without changing current
semantics or breaking any existing code. The point here is that a
complete type checker for Python is neither possible (Python has
dependent types, and in such a way as to make type checking undecidable),
nor necessarily desirable given Python's semantics. The tool therefore
provides a kind of 1/2 way house between static type checking and 
current Python.

For b):
I think some form of mark-and-sweep collection should be added to
Python (maybe a colouring one for better efficiency). This would
give full garbage collection. Maybe a command line flag could be
allowed saying whether or not you wanted to run Python with full
collection, so that C extensions didn't have problems. Actually I
don't believe that C extensions should have problems with garbage
collection if implemented correctly (just mark some blocks as
not being movable during compaction, or don't use a compacting
collector). Alternately make JPython the standard Python
implementation. I know that sounds radical but to my mind it has
a lot going for it (JVMs run everywhere, access to Java, access
to compilation, etc).

For c):
Use Swing and JPython.

graham


-- 
               Black velvet in that little boy's smile
                 Black velvet and a soft southern sky
            A new religion that'll bring you to your knees
                     Black velvet, if you please