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.mo...@gmail.com wrote: > > On Mon, 24 Feb 2020 at 16:23, Alex Hall alex.moj...@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. _______________________________________________ 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/RQTZ464QSQZUVIFROYSTGESP3FR3PFZD/ Code of Conduct: http://python.org/psf/codeofconduct/
