<p dir="ltr">On Aug 21, 2016 1:23 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> Now, if we were designing a language from scratch today, there's a<br>
> strong case to be made that the *right* way to represent text is to<br>
> have a stream-like interface (e.g. StringIO, BytesIO) around an atomic<br>
> type (e.g. CodePoint, int). But we're not designing a language from<br>
> scratch - we're iterating on one with a 25 year history of design,<br>
> development, and use.<br>
><br>
> There may also be a case to be made for introducing an AtomicStr type<br>
> into Python's data model that works like a normal string, but<br>
> *doesn't* support indexing, slicing, or iteration, and is instead an<br>
> opaque blob of data that nevertheless supports all the other usual<br>
> string operations. (Similar to the way that types.MappingProxyType<br>
> lets you provide a read-only view of an otherwise mutable mapping, and<br>
> that collections.KeysView, ValuesView and ItemsView provide different<br>
> interfaces for a common underlying mapping)<br>
><br>
> But changing the core text type itself to no longer be suitable for<br>
> use in text processing tasks? Not gonna happen :)</p>
<p dir="ltr">Thought: A string, in compsci, is, sort of by definition, a sequence of characters. It is short for "string of characters", isn't it?</p>
<p dir="ltr">If you were to create a new language, and you don't want to think of strings as char sequences, you might have a type called Text instead. Programmers could be required to call functions to get iterables, such as myText.chars(), myText.lines(), and even myText.words().</p>
<p dir="ltr">Thus, the proposal makes str try to be a Text type rather than the related but distinct String type.</p>