On Fri, 25 Aug 2006 08:48:34 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote: >On 8/25/06, Josiah Carlson <[EMAIL PROTECTED]> 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 _______________________________________________ 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
