On Mon, Feb 24, 2020 at 9:12 PM Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Feb 25, 2020 at 5:52 AM Alex Hall <alex.mojaki@gmail.com> wrote:
>
> Of course consistency is valuable. I am asking how it is automatically more valuable than "better or worse", which isn't an idea that makes sense to me. Consistency isn't axiomatically valuable, it's valuable for reasons such as what you've explained which ultimately boil down to what's better or worse. Those reasons can be outweighed by other considerations. Consistency is not *infinitely* valuable.
>

Thing is, "better or worse" could mean an extremely marginal
difference, whereas "consistent or inconsistent" is a fairly sharp
distinction. So it's a question of HOW MUCH worse it's okay to be, to
avoid being inconsistent. And actually it's okay to be quite a lot
worse in a vacuum, if it's better for consistency.

This response honestly seems to ignore most of the paragraph that it's responding to. It being a sharp distinction doesn't matter because consistency isn't axiomatically valuable. Its value has to be justified in context by real consequences, like with the JS example. Saying "it's okay to be quite a lot worse if it's better for consistency" is just blindly worshipping consistency. I don't know what "worse in a vacuum" means.

Also remember that iterating does not only mean "for x in y", but can
be seen in various other forms:

a, b, c = "foo"
list("foo")
dict.fromkeys("spam", "ham")

Getting a warning from one of these lines of code will not necessarily
explain the problem nor the correct solution.

Which is why I suggested a comprehensive message like:

"Strings are not iterable - you cannot loop over them or treat them as a collection. Perhaps you meant to use string.chars(), string.split(), or string.splitlines()?"

We can reword this or expand it to include more cases, it would definitely require some careful thought. I think mentioning unpacking is important, particularly for when someone forgets to use .items() when iterating over a dict.

And no, it wouldn't be perfect, but trying to figure out the problem when you've got an exact line of code and a specific googleable message that provides multiple possible causes is a much less harmful experience than trying to understand why your code is silently acting bonkers.
Even when there is a wealth of code out there that will become broken
by this change?

Not broken, just noisy.
 
It's creating inconsistency across data types within a
single Python version AND creating temporal inconsistency across
Python versions with a single operation.

As I said before, this holds no weight unless you expand on some actual consequences of these inconsistencies.