Re: Incremental step on road to improving situation around iterable strings
--- Bruce On Mon, Feb 24, 2020 at 1:19 PM Alex Hall <alex.mojaki@gmail.com> wrote:
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.
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?
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
On Mon, Feb 24, 2020 at 01:58:49PM -0800, Bruce Leban wrote:
I am interested to hear what kind of problem this was, and what strings lacked to allow you to solve them. When you say they weren't sufficiently performant, do you mean they lacked functionality, or they had the functionality but are too slow? -- Steven
participants (2)
-
Bruce Leban
-
Steven D'Aprano