Python Scalability

[dacut at kanga.org]

graham at sloth.math.uga.edu (Graham Matthews) wrote:
> 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.

Well, dodged might be a tad strong :-), but your reply is more along
the lines of what I've been looking for.

FWIW, I don't see a great benefit to adding abstract methods to a base
class object in Python, despite what everyone else has been advising.
It does add some clarity from a code aesthetics standpoint (which may
be reason in itself), but is useless from a functionality standpoint
since it effectively transforms the AttributeError exception into
something else.

> a) it does not provide any form of static typing, something I have
> 	 found to be essential on larger projects.

It's not so much static typing (though that is the easiest to think
about and the easiest to implement), but static interface checking.
This is essentially how C++ templates are done; unfortunately,
templates are still in their infancy and the error messages that result
leave a lot to be desired.

> b) it does't provide proper garbage collection (almost all my larger
> 	 Python apps leaked memory).

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).

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).  I've thought about building a version of
Python with this, but I'm not sure how to get at the "root" nodes
(i.e., those on the stack) without digging further into the Python VM.

> c) I didn't really like any of the GUI toolkits/frameworks.

I've had moderate success with Tkinter.  Unfortunately, the packer
geometry manager can be a bit unpredictable; results are *much* more
elegant with the placer, but you have to spend more time laying the
items out.  I've managed to create a fairly nice interface which has a
Java metal-ish feel to it (but without many of the widgets).

Agreed, though... I would like to see something like Swing.

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

Agreed wholeheartedly.  I just had a client today who was surprised at
how quickly an app ran.

> 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.

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.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---