Nick Coghlan <[EMAIL PROTECTED]> wrote: [snip] > that isn't likely to trigger an obvious error. It also breaks the persistent > idiom that "seq[:]" makes a copy (which is true throughout the standard > library, even if it isn't true for external number-crunching libraries like > NumPy).
The copying is easily fixed. I'm also not terribly concerned with the persistance of views, as I expect that most people who bother to use them (and/or care about the efficiency of str.partition, etc.) will know what they are getting themselves into. If they don't, then they will post on python-[list|dev], and we can give them a link to the string view documentation, which will explain what views are and how they can release the references to the original object: ref = str(ref) . > You also potentially end up with *every* sequence type ending up with a > "x-view" counterpart, which is horrible. OTOH, if we make the standard > library > more consistent in always using a slice or range object anytime it wants to > pass or return (start, stop, step) information, it provides a foundation for > someone to do their own non-copying versions. I'm not sure your slippery-slope argument holds. So far there are only a few objects for which views have been proposed with any substance: dictionaries, text and byte strings. The removal of buffer from 3.0 does leave an opening for other structures for which views (or even the original buffers) would make sense, like array and mmap, but those each have implementations that could effectively mirror the (mutable) byte string view. As for using slices to define a mechanism for returning view-like objects (it is effectively a different spelling), I don't particularly care for passing around slice/xrange objects. I would also like to mention that there exists external libraries that offer non-copying "views" to their underlying structures, the 'array interface' that was proposed in the last few months being a primary example of a desired standardization of such. > So with my musings, the non-copying index operation in a subsection would > still use an optional second argument: > > s.find(prefix, slice(start, stop)) This reduces the number of optional arguments by 1, and requires the somewhat explicit spelling out of the slice creation (which you attempt to remove via various syntax changes). I'm not sure these are actual improvements to either the string (or otherwise) API, or to the general sequence API. > If (start:stop:step) is equivalent to slice(start, stop, step), then slice > notation can be used to create ranges: range(start:stop:step) That looks like the integer slicing PEP that was rejected. Also, no one has been severely restricted by syntax; one could easily write a specialized object so that "for i in range[start:stop:step]" 'does the right thing'. - Josiah _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
