On Oct 25, 2019, at 01:34, Paul Moore <p.f.mo...@gmail.com> wrote: > > On Thu, 24 Oct 2019 at 23:47, Andrew Barnert via Python-ideas > <python-ideas@python.org> wrote: >> But again, I don’t think either of these is the reason Python strings being >> iterable is a problem; I think it really is primarily about them being >> iterables of strings. > > The *real* problem is that there's a whole load of functions that > would need rewriting to accept "character or string" arguments - or a > whole load of debating over whether they should only use one or > another.
That’s not the problem that this thread is trying to solve, it’s the problem with the solution to that problem. :) I’ve already said that I don’t think this is feasible, because it would be too much work and too disruptive to compatibility. If you were designing a new Python-like language today, or if you had a time machine back to the 90s, it would be a different story. But for Python 4.0—even if we wanted a 3.0-like break, which I don’t think anyone does—we can’t break all of the millions of lines of code dealing with strings in a way that forces people to not just fix that code but rethink the design. > And no cheating by saying these are cases where you should use > 1-character strings. The fact that people don't typically distinguish > between characters and 1-character strings in real life is precisely > why it's useful that Python currently doesn't make a distinction > either. Many of your examples are not cases where people should use 1-character strings; they’re cases where we need polymorphic APIs. But that’s not a problem. Countless other languages already do exactly that, and people use them every day. (The languages that are too weak to do that kind of polymorphism, like C and PHP, instead have to offer separate functions like strstr vs. strchr, which is manifestly less friendly. Fortunately, fact that Python’s core API was originally loosely based on C’s string.h wouldn’t in any way force the same problem on Python or a Python-like language.) And, while there are plenty of functions that would need to treat char and 1-char str the same, there are also many—not just iter—that should only work for one or the other, such as ord, or re.search. And there are also functions that should work for both, but not do exactly the same thing—char replacement is the same thing as translate; substring replacement is not. In fact, notice what happens if you call ord on a 2-char string today: TypeError: ord() expected a character, but string of length 2 found. Python is _pretending_ that it has a character type even though it doesn’t. And you find the same thing in third-party code: some of the functions people have written would need to handle str and char polymorphically, some would need to handle both but with different logic, and many would need to handle just one or the other. Which is exactly why it couldn’t be fixed with a 3to4 script, and people would instead need to rethink the design of a bunch of their existing functions before they could upgrade. > In case it's not glaringly obvious, I'm -1 on this, even as an > exercise in speculation :-) I’m -1 on this, but I think speculating on how it could be solved is the best way to show that it can’t and shouldn’t be solved. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IIRARPLSPKPG6CDPXHYFVNUT27JDET5N/ Code of Conduct: http://python.org/psf/codeofconduct/
