different string representation (buffer gap)
manders2k_NOSPAM at yahoo.com
Wed Feb 4 18:05:24 CET 2004
Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7xr7xbfjbe.fsf at ruckus.brouhaha.com>...
> You can do some of that with the array module, but Python's regexp
> library doesn't give any way to search backwards for a regexp, so that's
> another problem you'll face trying to write an editor in Python.
Yeah, I have a feeling that it might be easier to code up the buffer
in C/C++, and embed it in the interpreter. I'm not sure how much of a
performance bottleneck having this very low-level component written in
python will be on modern machines; probably not such a big deal.
Writing a buffer class and fiddling with pointers and whatnot actually
sounds easier to do in C++ than in emulating this style of thing in
Python (then again, I'm a heck of a lot more comfortable with C++ than
Python at this point, so that might not speak to the difficulty of the
What I guess I wish were the case is that I could implement the
"string interface" on my BufferGap, so that everywhere that Python (at
the C API level) expects a string, a BufferGap could be used instead.
That way, all the libraries that inspect and operate on strings would
work transparently, without having to be recoded (copy / paste, end up
with a lot of mostly identical, redundant code) to operate on this
other string representation. Maybe this just isn't possible with the
current C-Python implementation. I suspect it would be with many
possible C++-Python implementations, but we don't have one of those
lying around so...
I'm pretty sure that for modest size buffers (even a megabyte of
text), copying the contents of the buffer into a python-string
representation before operating on it with python-libraries would be
transparently fast. It just seems...wasteful, and potentially very
bad news if someone ever tried to do a regex search on a buffer that
occupied more than half of the physical memory of the machine or
More information about the Python-list