On May 4, 7:49 am, David <[EMAIL PROTECTED]> wrote: > > > 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.
Persistence on the rope class might be trivial; that is, a constant number of disk modifications be made per state modification. -- http://mail.python.org/mailman/listinfo/python-list