[Python-3000] Droping find/rfind?

[Jean-Paul Calderone]

On Fri, 25 Aug 2006 08:48:34 -0700, Guido van Rossum <guido at python.org> wrote:
>On 8/25/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>> 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.
>
>For the record, I think this is a major case of YAGNI. You appear way
>to obsessed with performance of some microscopic aspect of the
>language. Please stop firing random proposals until you actually have
>working code and proof that it matters. Speeding up microbenchmarks is
>irrelevant.

Twisted's core loop uses string views to avoid unnecessary copying.  This
has proven to be a real-world speedup.  This isn't a synthetic benchmark
or a micro-optimization.

I don't understand the resistance.  Is it really so earth-shatteringly
surprising that not copying memory unnecessarily is faster than copying
memory unnecessarily?

If the goal is to avoid speeding up Python programs because views are too
complex or unpythonic or whatever, fine.  But there isn't really any
question as to whether or not this is a real optimization.

Jean-Paul