Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> This idea is inspired by the find/rfind string discussion (particularly a
> couple of comments from Jim and Ron), but I think the applicability may prove
> to be wider than just string methods (e.g. I suspect it may prove useful for
> the bytes() type as well).
A couple comments...
I don't particularly like the idea of using lists (or really iter(list) ),
range, or slice objects as defining what indices remain for a particular
string operation. It just doesn't seem like the *right* thing to do.
> There are a couple of existing workarounds for this: buffer() objects, and
> the
> start/stop arguments to a variety of string methods. Neither of these is
> particular convenient to work with, and buffer() is slated to go away in Py3k.
Ahh, but string views offer a significantly more reasonable mechanism.
string = stringview(string)
Now, you can do things like parition(), slicing (with step=1), etc., and
all can return further string views. Users don't need to learn a new
semantic (pass the sequence of indices). We can toss all of the
optional start, stop arguments to all string functions, and replace them
with either of the following:
result = stringview(string, start=None, stop=None).method(args)
string = stringview(string)
result = string[start:stop].method(args)
Perhaps one of the reasons why I prefer string views over this indices
mechanism is because I'm familliar with buffers, the idea of just having
a pointer into another structure, etc. It just feels more natural from
my 8 years of C and 6 years of Python.
- Josiah
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
