[Python-3000] Making more effective use of slice objects in Py3k (original) (raw)

Guido van Rossum guido at python.org
Wed Aug 30 18:54:38 CEST 2006

I'd phrase it differently -- that would be plain silly. :-)

On 8/30/06, Paul Prescod <paul at prescod.net> wrote:

Yes, thanks for the clarification. From a type theory point of view there is nothing stopping string + view returning a view always (even if it is a view of a new string) but that would have very poor performance characteristics.

On 8/30/06, Guido van Rossum <guido at python.org> wrote: > The difference between a string and a view is one of TYPE. (Because > they can have such different performance and memory usage > characteristics, it's not right to treat them as the same type.) > > You seem to be misunderstanding what I said. I want the return type > only to depend on the input types. This means that all string and view > concatenations must return strings, not views, because we can always > create a new string, but we cannot always create a new view > representing the concatenation (unless views were to support disjoint > sections, which leads to insanity and the complexity and slowness of > ABC's B-tree string implementation). > > Assuming v and w are views: Just like v.lower() must sometimes create > a new string, which implies it must always return a string, v+w must > sometimes create a new string, so it must always return a string. > (It's okay to return an existing string if one with the appropriate > value happens to be lying around nearby; but it's not okay to return > one of the input views, because they're not strings.) > > Hope this clarifies things, > > --Guido > > On 8/30/06, Paul Prescod <paul at prescod.net> wrote: > > I don't understand. If the difference between a string and a string view is > > a difference of VALUES, not TYPES, then the return type is varying based > > upon the difference of input types (which you say is okay). Conversely, if > > the strings and string views only vary in their values (share a type) then > > the return code is only varying in its value (which EVERYBODY thinks is > > okay). > > > > Or maybe we're dealing with a third (new?) situation in which the > > performance characteristics of a return value is being dictated by the > > performance characteristics of the inputs rather than being predictable on > > the basis of the types or values. > > > > > > On 8/29/06, Guido van Rossum <guido at python.org > wrote: > > > > > On 8/29/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > > > Josiah Carlson wrote: > > > > This is changing return types based on variable type, > > > > > > How do you make that out? It seems the opposite to me -- > > > Guido is saying that the return type of s+t should not > > > depend on whether s or t happens to be a view rather than > > > a real string. > > > > No, I never meant to say that. There's nothing wrong with the type of > > x+y depending on the types of x and y. I meant that s+v, v+s and v+w > > (s being a string, v and w being views) should all return strings > > because -- in general -- they cannot always be views, and I don't want > > the return type to depend on the value of the inputs. > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) _> > ________________________ > > > > Python-3000 mailing list > > Python-3000 at python.org > > http://mail.python.org/mailman/listinfo/python-3000 > > Unsubscribe: > > http://mail.python.org/mailman/options/python-3000/paul%40prescod.net > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) >

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list