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

Guido van Rossum guido at python.org
Wed Aug 30 17:31:07 CEST 2006

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

More information about the Python-3000 mailing list