[Python-ideas] strings as iterables - from str.startswith taking any iterator instead of just tuple

Guido van Rossum guido at python.org
Sun Jan 5 08:24:03 CET 2014


Is this tread still about strings vs. other iterables?

First of all, the motivation for making strings iterable is that they
are indexable and sliceable, which means they act like sequences.

Historically, indexing and slicing predated the concept of iterators
in Python. Many other languages (starting with Pascal and C) also
treat strings as arrays; while many of those have a separate character
type, a few languages follow Python's example (or the other way
around, I don't feel like tracking the influences exactly, or even
finding examples -- I do know they exist). There are also languages
where strings are *not* considered arrays (I think this is the case in
Ruby and Perl). In such languages string manipulation is typically
done using regular expressions or similar APIs, although there usually
also non-array APIs to get characters or substrings using indexes, but
those APIs may not be O(1), e.g. for reasons having to do with
decoding UTF-8 on the fly.

All in all I am happy with Python's string-as-array semantics and I
don't want to change this.

While I would like to encourage API designs that don't require
distinguishing between strings and other iterables (just like I prefer
APIs that don't require distinguishing between sequences and mappings,
or between callables and "plain values"), I realize that pragmatically
people are going to want to write such code, and an ABC seems a good
choice.

However, if "Atomic" is still under consideration, I would strongly
argue against that particular term. Given that a string is an array of
characters, calling it an "atom" (== indivisible) seems particularly
out of order. (And yes, I know that the use of the term in physics is
also a misnomer -- let's not repeat that mistake. :-)

Alas, I don't have a better name, but I'm sure the thesauriers will
find something. We have until Python 3.5 is released to agree on a
name. :-)

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-ideas mailing list