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

[Guido van Rossum]

I'd phrase it differently -- that would be plain silly. :-)

On 8/30/06, Paul Prescod <paul at prescod.net> wrote:
> 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/)
> >
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)