> Conversely, I can't remember a case where I've ever accidentally
> iterated over a string when I meant not to.

Do you ever return a string from a function where you should have returned a list containing one string? Or similarly passed a string to a function? Forgotten to put a trailing comma in a singleton tuple? Forgotten to add .items() to `for key, value in kwargs:`?

> compelling arguments are typically
> around demonstrating how much code would be demonstrably better with
> the new behaviour

That represents a misunderstanding of my position. I think I'm an outlier among the advocates in this thread, but I do not believe that implementing any of the ideas in this proposal would significantly affect code that lives in the long term. Some code would become slightly better, some slightly worse. My concern surrounds the user experience when debugging code that accidentally iterates over a string. So it's impossible for me to show you code that becomes significantly better because that's not what I'm arguing about, and it's unfair to say that quoting people who have struggled with these bugs is not evidence for the problem.

Similarly for jdveiga, I cannot give you "real workable surprising code" because I'm talking about code that isn't workable as a result of being surprising. I have given examples of real non-working surprising code, and I can give more, and if that's not indicative of a real problem then I'm very confused and would appreciate more explanation.

On Mon, Feb 24, 2020 at 7:11 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Mon, 24 Feb 2020 at 16:23, Alex Hall <alex.mojaki@gmail.com> wrote:
> Roughly, though I think you might be hearing me wrong. There is lots of existing code that correctly and intentionally iterates over strings. And code that unintentionally does it probably doesn't live for long. But if you took a random sample of all the times that someone has written code that creates new behaviour which iterates over a string, most of them would be mistakes. And essentially the developer was 'wrong' in those instances. In my case, since I can't think of when I've needed to iterate over a string, I've probably been wrong at least 90% of the time.

Conversely, I can't remember a case where I've ever accidentally
iterated over a string when I meant not to. I *can* remember many
times when I've relied on strings being iterable.

Me quoting my experience is neither more nor less valuable than you
quoting yours. However, mine aligns with the current behaviour of
Python, and keeping things as they are so that my experience doesn't
change has no backward compatibility implications. So I don't need to
justify a preference that the language does what suits me best :-)

I don't think (I haven't checked the thread closely) that anyone is
saying your experience/expectation is "wrong". But to be sufficient to
result in a change in the language, you have to establish that your
behaviour is significantly *better* than the status quo, and I don't
think that you're doing that at the moment. And IMO, you're never
likely to do so simply by quoting numbers of people who do or don't
prefer the current behaviour - compelling arguments are typically
around demonstrating how much code would be demonstrably better with
the new behaviour, along with showing that code that is detrimentally
affected has an easy workaround. Your `.chars()` proposal targets the
latter question, but neither you, nor anyone else in past iterations
of this discussion, have yet come up with anything persuasive for the
former, that I'm aware of.

Paul