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

[Amber Yust]

For ABC names, perhaps "IndependentSequence" or "UnaffiliatedSequence"?
On Sat Jan 04 2014 at 11:25:23 PM, Guido van Rossum <guido at python.org>
wrote:

> 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)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140105/89a65c85/attachment-0001.html>