[Python-3000] Making strings non-iterable
Raymond Hettinger
rhettinger at ewtllc.com
Mon Apr 17 23:01:04 CEST 2006
Aahz wrote:
>On Sun, Apr 16, 2006, Tim Peters wrote:
>
>
>>Now that I think of it, though, I've been burned perhaps twice in my
>>total Python life by recursing on a string when I didn't intend to.
>>Apart from flatten()-ish functions, I'm not sure I've written anything
>>vulnerable to that.
>>
>>
>
>I've been burned a few times, but only because I was expecting a list
>input and got a string. I think that improving code analysis tools and
>making better use of unit tests is the proper cure for that.
>
>
-1 on making strings non-iterable. The cure is worse than the disease.
In ML, characters and strings are different datatypes and it is a
complete PITA. I suspect that making strings non-iterable would make
the language more difficult to use rather than simpler. Besides, if you
took away iterability, you would spend the rest of your life responding
to frequent requests to add it back ;-)
I'm also -1 on almost all proposals of this kind. IMHO, the first cut
of Py3000 should be directed at subtracting the cruft and consolidating
what we have. It should be a better Python, not just a different
Python. The surest route to that goal is to build on what has been
shown to work and experiment with random alternatives that may or may
not ultimately prove their worth.
What if this non-iterable string proposal were accepted and after a year
or so we found that there was a distaste for it that had reduced the
acceptance of the language? Alternatively, what if we found that
people just coded through it by reverting to pre-iterator style: for i
in range(len(s)): do_something(s[i])? I would hate to start seeing
code like that again.
Py3000 should try avoid the "second system effect" and not lose its
grounding. This includes proposals to put assignments in expressions,
new symbol syntaxes, and all the other random oddities being tossed out.
my two cents,
Raymond
More information about the Python-3000
mailing list