On 2016-08-20 21:10, Chris Angelico wrote:
>I think that while the suggestion does bring some benefit, the benefit
>isn't enough to make up for the code churn and disruption it would
>cause. But I encourage the OP to go through the standard library, pick a
>couple of modules, and re-write them to see how they would look using
>this proposal.
Python still has a rule that you can iterate over anything that has
__getitem__, and it'll be called with 0, 1, 2, 3... until it raises
IndexError. So you have two options: Remove that rule, and require
that all iterable objects actually define __iter__; or make strings
non-subscriptable, which means you need to do something like
"asdf".char_at(0) instead of "asdf"[0].

Isn't the rule that that __getitem__ iteration is available only if __iter__ is not explicitly defined? So there is a third option: retain __getitem__ but give this new modified string type an explicit __iter__ that raises TypeError.

That said, I'm not sure I really support the overall proposal to change the behavior of strings. I agree that it is annoying that sometimes when you try to iterate over something you accidentally end up iterating over the characters of a string, but it's been that way for quite a while and changing it would be a significant behavior change. It seems like the main practical problem might be solved by just providing a standard library function iter_or_string or whatever, that just returns a one-item iterator if its argument is a string, or the normal iterator if not. It seems that gazillions of libraries already define such a function, and the main problem is just that, because there is no standard one, many people don't realize they need it until they accidentally iterate over a string and their code goes awry.

Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail."
   --author unknown
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to