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

Paul Prescod paul at prescod.net
Wed Aug 30 18:04:47 CEST 2006

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/) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-3000/attachments/20060830/c77924b2/attachment-0001.html

More information about the Python-3000 mailing list