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/) _______________________________________________ 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
