Python Scalability

[Graham Matthews]

graham at sloth.math.uga.edu (Graham Matthews) wrote:
> a) it does not provide any form of static typing, something I have
> 	 found to be essential on larger projects.
dacut at kanga.org wrote:
: It's not so much static typing (though that is the easiest to think
: about and the easiest to implement), but static interface checking.

Just a minor point but static checking of interfaces is static type 
checking. Interfaces are essentially existential types, so checking 
interfaces is checking existential types, and hence is type checking.
So if I say "type checking" that includes interface checking :-)

graham at sloth.math.uga.edu (Graham Matthews) wrote:
> b) it does't provide proper garbage collection (almost all my larger
> 	 Python apps leaked memory).
dacut at kanga.org wrote:
: I would even argue that manual resource management is better than
: reference counting for this very reason.  Reference counting is fine
: when you have written all of the classes; in reality, this is never the
: case (e.g., I use Tkinter, and it holds a few references that I can't
: get at without reading the source).

Yes this is pretty much the problem I had with Python memory management.
No matter how careful I was someone else's code always leaked. Or I made
very unexpected circular references due to some implementation detail
of the Python interpreter.

dacut at kanga.org wrote:
: Personally, I'd like to see a Lins partial mark-sweep allocator; this
: is documented in Richard Jones and Rafael Lins' book _Garbage
: Collection: Algorithms for Automatic Dynamic Memory Management_.  It
: essentially combines reference counting (so if a ref count *does* drop
: to zero, an object is deallocated) with garbage collection (so those
: icky cycles get collected).  

Yes I would like to see a mark and sweep collector added to Python too.
Note that reference counting is actually coming back into favour as a
memory management scheme because it is good in distributed and real time
environments (since the cost of mem management is spread almost uniformly
across the code). In this context adding a fast mark and sweep collector
seems a natural thing to do.

graham at sloth.math.uga.edu (Graham Matthews) wrote:
> 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.
dacut at kanga.org wrote:
: And, frankly, this is all that you really need.  Just something to flag
: silly errors that may be difficult/tedious to test at run time.

Yes this seems like the minimalist position -- you don't change the current
semantics, nor get into difficulties with how to correctly type check
Python (a much harder issue than people seem to think). Instead you
accept a less than perfect type checking tool that does a lot of what
you want, without changing the current semantics.

graham
-- 
              Where do you think you're going
              Don't you know it's dark outside
              Where do you think you're going
              Don't you care about my pride