[Python-3000] Making strings non-iterable

[Raymond Hettinger]

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