[Python-Dev] Slice as a copy... by design?

[Hrvoje Nikšić]

On Thu, 2008-05-22 at 13:27 -0300, Facundo Batista wrote:
> 2008/5/22 Scott Dial <scott+python-dev at scottdial.com>:
> 
> > If we changed Python to slice-by-reference, then tomorrow someone would be
> > asking why it isn't slice-by-copy. There are pros and cons to both that are
> 
> Which are the cons of slice-by-reference of an immutable string?

You have to consider the ramifications of such a design choice.  There
are two cases to consider: either slices return strings, or they return
a different types.

If they return strings, then all strings must grow three additional
fields: start, end, and the reference to the actual string.  That is 16
more bytes for *every* string, hardly a net win.

You could argue that string slicing should return a separate type.  But
then, every piece of code that handles strings must be taught to handle
this type in addition.  PyString_Check and PyString_CheckExact must go.
Instead of writing PyString_Foo, the C code would have to use
PyObject_CallMethod and friends for the simplest tasks.  Time-saving
macros like PyString_AS_STRING and PyString_GET_SIZE become obsolete.
Where performance matters (as it often does in low-level C code dealing
with strings), this is a real problem.  Besides, you lose various
special optimizations, such as dicts being much faster when all keys are
strings.