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

[Paul Prescod]

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