[Zope] Zope needs this (and Dynamo has it)

[Martijn Faassen]

Alexander Staubo wrote:
> I definitely believe that Python is Zope's largest problem right now.
> It's also, from a technical point of view, one of it's biggest assets --
> Zope is becoming the killer application of Python, and might eventually
> become the driving force to evolve Python, which is, I believe,
> suffering from draught into the contributor department. Skilled
> developers aren't flocking to Python to make it faster. Not right now,
> anyway.

Hm, skilled developers do hack on Python! There's the Python people at
CRNI, there's Christian Tismer in Germany doing Stackless Python (which
offers interesting arcane features and a mild performance improvements),
there's the whole JPython group, there's John Skaller with his Vyper
project (a Python interpreter/compiler in Ocaml, one of the reasons
is more speed). Then there's the Python Types-SIG, which I urge you to
look at if you haven't already.

> My hope is that Zope will change this, because Python has possibly one
> of the slowest interpreters on earth. Python zealots -- and there is
> such a beast -- will tell you that Python's performance is less of a
> matter because what you sacrifice in speed you gain in power, ie.
> computational expressiveness through a high-level, dynamic language.

It is _less_ of a problem, but most Pythoneers are indeed interested in
speeding of the language. I haven't heard of zealots who want to hold
back speedups, as long as it doesn't do away with the power.

> For an example of a good, Python-like, dynamic language that is also
> very fast, take a look at Dylan. In current implementations, Dylan is
> not interpreted but rather compiled to native code, but in theory there
> is nothing stopping anyone from writing a highly efficient Dylan
> interpreter. Dylan's magic comes from its use of type hints, a system
> which I had recognized as likely pivotal to improving Python's
> interpreter long before I knew of Dylan.

It'll be pretty difficult to make a beast like Zope exploit type-hints, though,
I think. By the way, the Types-SIG is working on type extensions to Python,
partially for performance (OPT), partially for better error checking (ERR)
and partially for better documentation (DOC). See:

http://www.python.org/sigs/types-sig/

And also see the new compiler SIG:

http://www.python.org/sigs/compiler-sig/

> In Dylan, specifying a
> variable's type is optional. When omitted, the Dylan compiler will
> usually be able to infer the type from what you do with the variable
> (ie., it sees you're assigning an integer to it; hence it can assume
> that, for at least a stretch of execution, the variable remains an
> integer). When you explicitly declare a variable's type, Dylan applies
> the necessary code optimizations (such as using tight integer maths or
> string copying) as well as static type checking. In Python, variables
> can hold virtually anything, and this incurs a huge amount of checks.

Type inference is not a simple thing to add to the language, though..

> Just imagine -- while Zope is running, thousands and thousands of the
> same little checks are performed continuously, over and over again,
> amounting to no uncertain overhead.

That's of course true. I heard Christian Tismer talk about making a 
register machine interpreter for Python, which could potentially speed
things up quite a bit. I shall ask him about this idea again sometime. :)

> Python's biggest overhead comes from its dynamism -- the dynamic typing,
> as explained, combined the object allocation system: most things is an
> object, so a lot of objects are constantly spawned and torn down, often
> in rapid succession because the compiler/interpreter can make few hard
> analyses of when stuff is needed. Python also has a high function-call
> overhead.

All true. Anyway, the only thing you're wrong about is that Pythoneers aren't
interested in improving performance. They are, but I grant you they're not
performance nuts like users of C or C++. :)

Regards,

Martijn