Greg Ewing <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > If every operation on a view returned a string copy, then what would be > > the point of the view in the first place? > > String views would have all the same methods as a real > string, so you could find(), index(), etc. while operating > efficiently on the original data. To my mind this is > preferable to having little-used optional arguments on > an easily-forgotten subset of the string methods: you > only have to remember one thing (how to create a view) > rather than a bunch of random things.
Indeed, and all of those are preserved if views always returned views, strings always returned strings, and one used the standard constructors for both to convert between them; eg. str(view) -> str and view(str) -> view. If one ever wanted a string from a view, rather than guessing which would be the correct one to return (during the implementation of views), always return a view when operating on views; it's a constant-time operation per view returned, and if the user really wanted a string, they can always call str on the returned values. > For some things, such as partition(), it might be worth > having a variant that returned views instead of new strings. > But it would be named differently, so you'd still know > whether you were getting a view or not. But wouldn't it be confusing if some methods on views returned views, while others returned strings? Wouldn't it make more sense if methods on an object, generally, returned instances of the same type (when it made sense)? This seems to be the case with almost every other object available in the Python standard library, with the notable exceptions of buffer and mmap. The slicing operations on mmaps make sense, as only recently did mmaps gain the ability to map partial files not starting from the beginning, but I'm not sure how well operating system would handle overlapping mmaps in the same process (especially during a larger mmap free; that could bork the heap address space). For buffer? I don't know. Buffer lacks basically every operation that I use on a string, so I have had little use for it except as a way of virtually slicing mmaps (for operations where I don't want to pass an offset argument) and handling socket writing of large blocks of data that it doesn't make sense to pre-slice*. > I'm not personally advocating one approach or the other > here -- just pointing out an alternative that might be > more acceptable to the BDFL. Thank you for the input (and thank you for Pyrex, it's making writing the view object quite easy), - Josiah * Arguably it never makes sense to pre-slice; connection speeds can vary so significantly that choosing a slice too small results in poor speeds and high numbers of system calls, and slices that are too large results in further slicing. Buffers or their equivalents win by a large margin. One trick is to slice the buffer (turning it into a string) when over half of the original string has been written. This results in using at most 2x the minimum amount of memory necessary, while also guaranteeing that you will only ever slice as much as the minimum pre-slicing operation would necessitate. _______________________________________________ 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
