I'd phrase it differently -- that would be plain silly. :-) On 8/30/06, Paul Prescod <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > wrote: > > > > > > > On 8/29/06, Greg Ewing <[EMAIL PROTECTED]> 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 > > > [email protected] > > > 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/) _______________________________________________ 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
