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:
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
On Mon, 24 Feb 2020 at 16:23, Alex Hall <alex.mojaki@gmail.com> wrote: 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