This was a CPython idea after all, so I was assuming a C implementation, which means that new flags would have to be added to the string object to denote a string slice, etc.

Like I said in another message: it's not that important to me though.  I was just curious as to why CPython was designed so that string slicing is linear rather than constant time given that strings are constant.

I'm getting the impression that the payoff is not worth the complexity.

On Thu, May 7, 2015 at 4:12 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
I haven't seen anyone else mention it, so I will point out: interoperability with C. In C, strings are NUL-terminated. PyStringObject instances do (or used to) have NUL-terminated strings in them. According to unicodeobject.h, that seems still to be the case:

typedef struct {
    /* There are 4 forms of Unicode strings:
    ...
    wchar_t *wstr;              /* wchar_t representation (null-terminated) */
} PyASCIIObject;

and:

typedef struct {
    PyASCIIObject _base;
    Py_ssize_t utf8_length;     /* Number of bytes in utf8, excluding the
                                 * terminating \0. */
    char *utf8;                 /* UTF-8 representation (null-terminated) */
    Py_ssize_t wstr_length;     /* Number of code points in wstr, possible
                                 * surrogates count as two code points. */
} PyCompactUnicodeObject;

The raw string is NUL-terminated, precisely so copying isn't required in most cases before passing to C. Making s[1:-1] a view onto the underlying string data in s would require you to copy the data when you want to pass the view into C so you could tack on that NUL. That happens a lot, so it's likely you wouldn't save much work, and result in a lot more churn in Python's memory allocator. The only place you could avoid the copy is if the view you are dealing with is a strict suffix of s.

Skip

--

---
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/II-4QRDb8Is/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

--

---
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/II-4QRDb8Is/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.