[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