I think maybe you forgot to reply to the list as well?
I did mean to reply to the list, so adding it back in.
How many scripts do you have where your own code directly iterated over a string? How hard do you think it would be to update that code?
Actually quite a bit. I write a lot of code that manipulates words to create puzzles. In every one of those I use strings as iterables. For what it's worth, in one of these programs, the problem I encountered was that strings were not sufficiently performant to solve a very complex problem. I modeled the strings as integers, and built the subset of needed string-like operations on them -- including iteration.
If the warning comes from a dependency that hasn't updated, you can simply add the appropriate code to filter that category of warnings. I think you have the option of two lines of Python code or one environment variable.
That's not a good answer IMHO. Warnings should matter. Telling me I can filter them out means it shouldn't be there in the first place. And I have to filter them out because warnings that don't matter obscure the ones that do.
As for your sample, this has been requested twice by others, here was my response:
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.
The claim was made by someone that certain code is "problematic" because the strings are iterable. Asking to see before and after code is certainly relevant, so we can see exactly what the "problem" is and how it gets better. Maybe the code gets *worse* and debugging gets easier. That tradeoff is relevant. And more to the point, is there anything that can't be done by a better linter instead of mucking up the language?
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.
Now my question is, what is the worst damage that this change could cause? Because I haven't heard an argument that goes deeper than aesthetics.
The worst damage? The change generates spurious warnings from millions of lines of correct code. It annoys people to the extent they no longer think Python is a stable platform to use to build code. Python dies.
Sure that worst case isn't likely but you asked. The bar for changing such a core feature of Python is much higher than "the worst case isn't going to kill the language." In my opinion, declaring code deprecated when there is zero likelihood that it will ever be removed is counter-productive at best.
--- Bruce