[Python-Dev] Slice as a copy... by design? (original) (raw)

Hrvoje Nikšić hrvoje.niksic at avl.com
Mon May 26 11:21:35 CEST 2008

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.

More information about the Python-Dev mailing list