[Christian Tismer]
> ...
> Then a string should better not be a sequence.
>
> The number of places where I really used the string sequence
> protocol to take advantage of it is outperfomed by a factor
> of ten by cases where I missed to tupleise and got a bad
> result. A traceback is better than a sequence here.
Alas, I think
for ch in string:
muck w/ the character ch
is a common idiom.
> oh-what-did-I-say-here--duck--but-isn't-it-so--cover-ly y'rs - chris
The "sequenenceness" of strings does get in the way often enough. Strings
have the amazing property that, since characters are also strings,
while 1:
string = string[0]
never terminates with an error. This often manifests as unbounded recursion
in generic functions that crawl over nested sequences (the first time you
code one of these, you try to stop the recursion on a "is it a sequence?"
test, and then someone passes in something containing a string and it
descends forever). And we also have that
format % values
requires "values" to be specifically a tuple rather than any old sequence,
else the current
"%s" % some_string
could be interpreted the wrong way.
There may be some hope in that the "for/in" protocol is now conflated with
the __getitem__ protocol, so if Python grows a more general iteration
protocol, perhaps we could back away from the sequenceness of strings
without harming "for" iteration over the characters ...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4