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. Here's how I think the journey for a beginner discovering this stuff would go. First they run some code that iterates directly over a string. And doing so works, because I'm not advocating removing iterability at any point. But a warning with some message about iterating over a string shows up. It suggests using `.chars()`, which they do, and the warning goes away. That would probably be the end of it. From the assumptions in this scenario, we're talking about a beginner - specifically one who might have trouble understanding the kinds of things we're discussing, and who has never iterated over a string before (which, if I am to be generous to your side, is supposedly a common activity). I don't think it's likely that they will have drawn the connection yet between indexing and iteration. But let's assume they have, and they're curious why they got a warning. Or more likely, let's assume that they don't immediately figure out what to do from the warning message. The obvious next step is to search for the message online. This is a specific warning regarding iterating over strings, so the results will specifically be about this topic. Through Google's algorithm and Stack Overflow's votes, they will probably land on an explanation that is widely regarded as one of the best online, so probably better than what I'm about to offer. But here's what I would write: "Iterating through a string has always meant iterating over its characters. But there aren't many situations where this is useful. In most cases iterating over a string directly is a sign that a mistake has been made, such as passing a string to a function instead of a list containing one string. This often leads to mysterious behaviour that can be hard to understand and fix. To help users find these mistakes more quickly, the warning was added in recent versions of Python, along with the chars() method to signal to both human readers and Python the intent to iterate over characters. This makes strings a gentle exception to the common convention that indexing and iteration have matching behaviour." To be fair, I think many users will not initially understand the explanation. But they will move on with their lives. Eventually though, they will accidentally iterate over a string, and the warning will appear again, and this time it will probably be helpful to them. Then, whether or not they remember the explanation, or even if they didn't read it in the first place, they will probably start to understand why that warning exists. And that's the 'worst case' scenario from the perspective of your comment. I think the most likely scenario is that they will see the warning in a helpful context before they try iterating over a string, so they will have some experience to help them understand before they get a chance to wonder about the inconsistency. So in a nutshell: 1. I think that users being confused about this inconsistency is not going to harm them as much as you seem to be claiming. 2. I think that users will learn to understand the reasoning behind inconsistency from practical experience, more than any explanation. By contrast, the examples you've given are definitely harmful and difficult to understand. I've been personally baffled by the first example <https://stackoverflow.com/questions/37230877/why-cant-i-store-a-reference-to-elem-show-and-call-it-later>. But the real problem with them is deeper than inconsistency. The problem is that they are surprising, confusing, and difficult to debug. Which is exactly the kind of bug that the proposed warning is meant to defend against, and definitely not the kind of problem that will be caused by seeing said warning and contemplating inconsistencies in the data model. On Mon, Feb 24, 2020 at 6:37 PM Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Feb 25, 2020 at 3:21 AM Alex Hall <alex.mojaki@gmail.com> wrote:
It is not a question of right or wrong, better or worse. It is a question of being consistent.
Why would that be the question? Why is consistency more important than "better or worse"? How can you make such a bold claim?
Inconsistency leads to ridiculous situations where things change from working to nonworking when you make what should be an insignificant change. Consider:
// JavaScript let obj = { attr: 1, method: function() {return this.attr;}, } obj.method() # returns 1 [obj.method][0]() # returns undefined
// PHP, older versions - fortunately fixed function get_array() {return array(1, 2, 3);} $arr = get_array(); echo $arr[0]; // Fine echo get_array()[0]; // Broken until PHP 5.something
# Python nan = float("nan") nan == nan # False [nan] == [nan] # True
Go ahead, explain these differences to a newish programmer of each language. Explain why these behave differently.
Now would you like to explain why, with strings, you can say s[0], s[1], s[2] etc, but you can't iterate over it, either with a 'for' loop or with any other construct that iterates (for instance, you can't say a,b,c = s because that is done with iteration). Especially, explain why you can do this with literally every other subscriptable type in the core language (and most from third-party classes too), and it's only strings that are bizarre. Oh but they *aren't* bizarre in older versions, so there'll be code on the internet that works that way, just don't do it any more.
Have fun explaining that. Consistency *is* valuable.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/547XBH... Code of Conduct: http://python.org/psf/codeofconduct/