[Python-3000] Droping find/rfind?

[Josiah Carlson]

"Fredrik Lundh" <fredrik at pythonware.com> wrote:
> Jean-Paul Calderone wrote:
> 
> >>> I believe you're thinking about something far more sophisticated than what I'm
> >>> suggesting. I'm just talking about a Python data type in a standard library
> >>> module that trades off slower performance with smaller strings (due to extra
> >>> method call overhead) against improved scalability (due to avoidance of
> >>> copying strings around).
> >>
> >>have you done any benchmarking on this ?
> >
> > I've benchmarked string copying via slicing against views implemented using
> > buffer().  For certain use patterns, views are absolutely significantly
> > faster.
> 
> of course, but buffers don't support many string methods, so I'm not sure how
> that's applicable to this case.
> 
> (and before anyone says "let's fix that, then", please read earlier messages).

Aside from the scheduled removal of buffer in 3.x, I see no particular
issue with offering a bytes view and str view in 3.x via two specific
bytes and str subtypes.  With care, very few changes if any would be
necessary in the str (unicode) implementation, and the bytesview
consistancy updating is already being done with current buffer objects.

From there, the only quesion is when an operation on a bytes or str
object should return such a view, and the answer would be never.  Return
views from view objects, the non-views from non-view objects.  If you
want views, wrap your original object with a view, and call its methods. 
If you need a non-view, call the standard bytes/str constructor.

 - Josiah