Python is faster than C

[Armin Rigo]

Paul Rubin wrote:
> I think you're saying that instead of having xrange return a special
> object, range should return that special object instead.  I'm not too
> clear on the distinction.

No, range should return an object that is a list, as far as you can tell
from Python, but which is represented more efficiently than an array of
objects internally.  The distinction is between the language level (it
would be a list, with all operations, etc.) and the implementation
(there is no reason why all lists should be arrays of PyObjects
internally).

Another example would be 'a'*999999999: the result is a string, but
there is no reason that it takes 100MB of memory.  Instead, store it
into a C structure that contains a pointer to the original string object
'a' and the repetition counter, but still give this C structure the
Python type str, so that the difference doesn't show up and the Python
language remains simple.  (This is a bit difficult to implement
currently in CPython, but not impossible.)

> Also, how can the compiler or interpreter
> know whether the program will only access the object sequentially?
> It has to predict the behavior of the program, instead of being told
> explicitly.

Ideally: If you do  x=range(100); x[50]='hi'  then the interpreter first
builds this optimized range representation and assigns it to x; and when
in the next statement you modify this list x it says 'oops! i cannot do
that with this representation', so it reverts to an array-like
representation (i.e. it creates all 100 elements) and then changes the
50th.  No gain here.  If on the other hand you only ever do 'easy'
things with your list, like iterate over it or read elements, then it
can all be done with the range representation, without falling back to
the array representation.

Again I'm not saying it is trivial to implement it, but that not having
to expose for optimization purposes 'xrange' and the whole 'iterator'
part of the language would be worth it, in my opinion.


Armin