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

["Martin v. Löwis"]

> I couldn't answer why, so I'm asking here...Is it because the
> reference counting will be complicated? Is it because it'd be
> inefficient in other way? It's something else? Or is something that
> could be done... but is not done yet?

There are two problems with that approach:

a) you may hold onto very long strings for a long time, even though
   you don't "see" the larger string anymore, e.g. when you have only
   a single line of an entire file that you hold onto. That, in turn,
   may cause the program to consume much more memory than the copying
   slicing.
b) it is very difficult to implement and maintain. At any point in the
   code that deals with string representations, you have to make the
   distinction of whether you have a "real" string, or a slice. Nobody
   has contributed a correct and efficient implementation of that yet,
   let alone one that is also easy to maintain.
c) (related to b) Currently, the string object's internal representation
   might be used in extension modules. We would need to find a way to
   protect against errors that may occur when we silently change the
   representation semantically.

(as any good list of two items, this has three :-)

Regards,
Martin