On Aug 21, 2016 1:23 AM, "Nick Coghlan" <ncogh...@gmail.com> wrote: > Now, if we were designing a language from scratch today, there's a > strong case to be made that the *right* way to represent text is to > have a stream-like interface (e.g. StringIO, BytesIO) around an atomic > type (e.g. CodePoint, int). But we're not designing a language from > scratch - we're iterating on one with a 25 year history of design, > development, and use. > > There may also be a case to be made for introducing an AtomicStr type > into Python's data model that works like a normal string, but > *doesn't* support indexing, slicing, or iteration, and is instead an > opaque blob of data that nevertheless supports all the other usual > string operations. (Similar to the way that types.MappingProxyType > lets you provide a read-only view of an otherwise mutable mapping, and > that collections.KeysView, ValuesView and ItemsView provide different > interfaces for a common underlying mapping) > > But changing the core text type itself to no longer be suitable for > use in text processing tasks? Not gonna happen :)
Thought: A string, in compsci, is, sort of by definition, a sequence of characters. It is short for "string of characters", isn't it? 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(). Thus, the proposal makes str try to be a Text type rather than the related but distinct String type.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
