[Python-3000] Making strings non-iterable

[Ian Bicking]

Raymond Hettinger wrote:
> -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 ;-)

The proposal wasn't to remove iterability in general, only to require
the use of an explicit method when iterating over strings.  It's not a
huge change by any means; a speed bump for a small number of people,
perhaps, but no real functionality would be removed.  Backward
compatibility is also certainly a concern -- and what seems to have
soured Guido on the idea as much as anything -- but that doesn't seem to
be what has you bothered.

Also, there was no proposal to add a character type.  It was noted that
the lack of a character type is part of what makes string iteration
problematic, because strings are not character containers, and iteration
over a string actually produces a set of slices of the string, it
doesn't expose the contents of the string.  I think Greg proposed
removing __getitem__, but that seems a bit extreme.  So I don't think
there's any parallel to ML or other languages with character types.

> 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.

I don't see how this is so dramatically different.  I proposed it
specifically to remove something that at least I considered a language
wart: an area prone to errors that provides an interface inconsistent
with other parts of the language.

> 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.

I would hope that in any finished version the exception message would
point people to .chars(), or perhaps simply signal a warning with the
same message to begin with.  Py3k is going to be used for a while before
any part of it is truly committed to, so it's perfectly fine if things
go in and are then retracted.

> 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.

Those are all rather conservative proposals; I don't see how second
system comes into it.  Type annotations might fall in that realm,
'make', some others... but suggesting some syntactic twiddling, though
perhaps not very useful, is not second system effect.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org