Alex Hall wrote:
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
If you can provide a real code of strings wrongdoing, I will be convinced. On the contrary, you have provided two examples --as long as I can remember-- on the expected and implemented behaviour of strings in Python. Nothing wrong on language implementation. Just your desire that things work in a different manner -- but this is not suffice to change the foundations of any programming language: start your own language if you feel so disappointed; Guido did. I am really eager to be convinced. Please, show us a snippet that proves your point of view. If you cannot, accept that Python's string model is just a convention and that programming languages are purely conventional. Computation is not about Python, or Lisp, or Java, is about algorithms.