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

Paul Prescod paul at prescod.net
Wed Aug 30 17:16:39 CEST 2006


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060830/5916c974/attachment.htm 


More information about the Python-3000 mailing list