[Python-3000] Making more effective use of slice objects in Py3k

[Guido van Rossum]

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