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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4