Light slices + COW

[David]

>  > D compiles to efficient machine code so Python is at a disadvantage
>  > even if you use the same syntax (see my first example). You can make
>  > the Python version faster, but beware of premature optimization.
>
>  This time I don't agree with this "premature optimization" thing. My
>  original Python version is just 5 lines long, it's readable enough,
>  and it's a part of a large library of mine of similar functions, they
>  must be fast because I use them all the time as building blocks in
>  programs.
>

Have you looked into the 'numpy' libraries? Those have highly
optimized array/numeric processing functions. Also the have a concept
of getting 'views' when you slice, rather than a full copy.

I also suggest benchmarking your apps which use your libs and see
where the bottlenecks are. Then you can move those to external
compiled modules (c/pyrex/cython/shedskin/etc). You can keep your
slower Python version around as a reference implementation.

>  > What I'dlike to see is a rope[1] module for Python.
>
>  People have already suggested it, and there's even an implementation
>  to replace Python strings. It was refused because... I don't know why,
>  maybe its implementation was too much more complex than the current
>  one, and it wasn't faster in all situations (and I think Guido wants
>  data structures that try to replace the basic built-in ones to be
>  faster in all situations and user-transparent too).

I'd be happy if there was a separate 'rope' class that you could wrap
arbitrary long sequences in when you need to (the same way that STL
has it separate to the string class, even though the string class has
a lot of other optimizations (internal ref counts, etc, to avoid
unnecessary copies)). Do you know one?

David.