python simply not scaleable enough for google?

Robert Brown bbrown at
Sat Nov 14 08:20:44 CET 2009

Vincent Manis <vmanis at> writes:

> On 2009-11-13, at 17:42, Robert Brown wrote, quoting me: 

>> ... Python *the language* is specified in a way that
>> makes executing Python programs quickly very very difficult.  

> That is untrue. I have mentioned before that optional declarations integrate
> well with dynamic languages. Apart from CL and Scheme, which I have
> mentioned several times, you might check out Strongtalk (typed Smalltalk),
> and Dylan, which was designed for high-performance compilation, though to my
> knowledge no Dylan compilers ever really achieved it.

You are not making an argument, just mentioning random facts.  You claim I've
made a false statement, then talk about optional type declarations, which
Python doesn't have.  Then you mention Smalltalk and Dylan.  What's your
point?  To prove me wrong you have to demonstrate that it's not very difficult
to produce a high performance Python system, given current Python semantics.

>> I'm tempted to say it's impossible, but great strides have been made
>> recently with JITs, so we'll see.
>> If you want to know why Python *the language* is slow, look at the Lisp
>> code CLPython generates and at the code implementing the run time.  Simple
>> operations end up being very expensive.  Does the object on the left side
>> of a comparison implement compare?  No, then does the right side implement
>> it?  No, then try something else ....

> I've never looked at CLPython. Did it use a method cache (see Peter
> Deutsch's paper on Smalltalk performance in the unfortunately out-of-print
> `Smalltalk-80: Bits of History, Words of Advice'? That technique is 30 years
> old now.

Please look at CLPython.  The complexity of some Python operations will make
you weep.  CLPython uses Common Lisp's CLOS method dispatch in various places,
so yes, those method lookups are definitely cached.

Method lookup is just the tip if the iceburg.  How about comparison?  Here are
some comments from CLPython's implementation of compare.  There's a lot going
on.  It's complex and SLOW.

   ;; This function is used in comparisons like <, <=, ==.
   ;; The CPython logic is a bit complicated; hopefully the following
   ;; is a correct translation.

   ;; If the class is equal and it defines __cmp__, use that.

   ;; The "rich comparison" operations __lt__, __eq__, __gt__ are
   ;; now called before __cmp__ is called.
   ;; Normally, we take these methods of X.  However, if class(Y)
   ;; is a subclass of class(X), the first look at Y's magic
   ;; methods.  This allows the subclass to override its parent's
   ;; comparison operations.
   ;; It is assumed that the subclass overrides all of
   ;; __{eq,lt,gt}__. For example, if sub.__eq__ is not defined,
   ;; first super.__eq__ is called, and after that __sub__.__lt__
   ;; (or super.__lt__).
   ;; object.c - try_rich_compare_bool(v,w,op) / try_rich_compare(v,w,op)

   ;; Try each `meth'; if the outcome it True, return `res-value'.

   ;; So the rich comparison operations didn't lead to a result.
   ;; object.c - try_3way_compare(v,w)
   ;; Now, first try X.__cmp__ (even if y.class is a subclass of
   ;; x.class) and Y.__cmp__ after that.

   ;; CPython now does some number coercion attempts that we don't
   ;; have to do because we have first-class numbers. (I think.)

   ;; object.c - default_3way_compare(v,w)
   ;; Two instances of same class without any comparison operator,
   ;; are compared by pointer value. Our function `py-id' fakes
   ;; that.

   ;; None is smaller than everything (excluding itself, but that
   ;; is catched above already, when testing for same class;
   ;; NoneType is not subclassable).

   ;; Instances of different class are compared by class name, but
   ;; numbers are always smaller.

   ;; Probably, when we arrive here, there is a bug in the logic
   ;; above. Therefore print a warning.

More information about the Python-list mailing list