>
> So you can't lose iteration without also losing subscripting.
>>>
>>
>> Python here does a lot of things implicitly. I always felt the
>> (explicit) index operator in strings in many other languages sort of is
>> syntactic sugar, in python it was taken to do literally the same things as
>> on other objects. But it does not have to be that way.
>>
>
> You can quibble with the original design choice, but unless you borrow
> Guido's time machine, there's not much point to that discussion.
>
Just to be clear, at the time it was designed, it surely was a genious idea
with its obvious simplicity.
I spend much of my time refactoring codes and interfaces from previous
"genius" ideas, as usage matures.
> Instead, let's talk about the benefits and problems that your change
> proposal would cause.
>
> Benefits:
> - no more accidentally using str as an iterable
>
> Problems:
> - any code that subscripts, slices, or iterates over a str will break
>
I would try to keep indexing and slicing, but not iterating. Though there
have been comments that may not be straightforward to implement. Not sure
if strings would need to acquire a "substring" attribute that can be
indexed and sliced.
Did I leave anything out?
> How would you weigh the benefits against the problems?
> How would you manage the upgrade path for code that's been broken?
>
FIrst one needs to add the extension string attributes like
split()/split(''), chars(), and substring[] (Python 3.7).
When indexing becomes disallowed (Python 3.10 / 4.0) attempts to iterate
(or slice) will raise TypeError. The fixes overall will be a lot easier
and obvious than introduction of unicode as default string type in Python
3.0. It could already be used/test starting with Python 3.7 using 'from
future import __monolythic_strings__`.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
