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
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".
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.
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/