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