On Sun, Aug 21, 2016 at 12:34:02AM +0000, Michael Selik wrote: > So anything that wants to loop over a string character by character would > need to construct a new object, like ``for c in list(s)``? That seems > inefficient. I suppose you might advocate for a new type, some sort of > stringview that would allow iteration over a string, but avoid allocating > so much space as a list does, but that might bring us back to where we > started.
If this was ten years ago, and we were talking about backwards incompatible changes for the soon-to-be-started Python 3000, I might be more responsive to changing strings to be an atomic type (like ints, floats, etc) with a .chars() view that iterates over the characters. Or something like what Go does (I think), namely to distinguish between Chars and Strings: indexing a string gives you a Char, and Chars are not indexable and not iterable. But even then, the change probably would have required a PEP. > > The fixes overall will be a lot easier and obvious than introduction of > > unicode as default string type in Python 3.0. > > That's a bold claim. Have you considered what's at stake if that's not true? Saying that these so-called "fixes" (we haven't established yet that Python's string behaviour is a bug that need fixing) will be easier and more obvious than the change to Unicode is not that bold a claim. Pretty much everything is easier and more obvious than changing to Unicode. :-) (Possibly not bringing peace to the Middle East.) I think that while the suggestion does bring some benefit, the benefit isn't enough to make up for the code churn and disruption it would cause. But I encourage the OP to go through the standard library, pick a couple of modules, and re-write them to see how they would look using this proposal. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
