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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
