On Mon, 2006-04-17 at 14:01 -0700, 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 ;-)
Thing is, strings more so than any other collection want to be treated sometimes atomically and sometimes as a collection. You don't read the word "string" as ess, tee, are, eye, en, gee, you read it as the atomic unit "string". This is true in other languages than Python too, but in Python by default historically the sequential nature of strings takes precedence over the atomic nature of strings. I think there's value in exploring making strings atomic by default, and having to be explicit when you want to treat strings like a collection. I think the majority of programming uses of strings is as an atomic unit, not as a collection of characters. Sure, you might want to treat a string as a sequence of characters to iterate over them, but I believe that is a minority use case and so should not be implicitly supported. I haven't followed the views topic too closely, but ISTM little penalty to have to say "for c in mystring.characters()" for the very rare times I want to iterate over all the characters in a string (as opposed to taking a slice or checking startswith() or endswith()). It also seems like a price worth paying to not have to say "if not isinstance(s, basestring)" when flattening. It may not be possible to make this change for practical reasons, but I think that treating strings as atoms by default makes sense. -Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
