"Fredrik Lundh" <[EMAIL PROTECTED]> 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 _______________________________________________ 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
