[Python-ideas] discontinue iterable strings
Brendan Barnwell
brenbarn at brenbarn.net
Sun Aug 21 01:06:07 EDT 2016
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
More information about the Python-ideas
mailing list