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/

Reply via email to