This would introduce a major inconsistency. To do this, you would need to also
strip string’s of their status as sequences (in collections.abc, Sequence is a
subclass of Iterable). Thus, making string’s no longer iterable would also mean
you could no longer take the length or slice of a string.
While I believe your proposal was well intentioned, IMHO it would cause a giant
inconsistency in Python (why would one of our core sequences not be iterable?)
- Ed
> On Aug 19, 2016, at 11:13 PM, Alexander Heger <pyt...@2sn.net> wrote:
>
> standard python should discontinue to see strings as iterables of characters
> - length-1 strings. I see this as one of the biggest design flaws of python.
> It may have seem genius at the time, but it has passed it usefulness for
> practical language use. For example, numpy has no issues
>
> >>> np.array('abc')
> array('abc', dtype='<U3')
>
> whereas, as all know,
>
> >>> list('abc')
> ['a', 'b', 'c']
>
> Numpy was of course design a lot later, with more experience in practical use
> (in mind).
>
> Maybe a starting point for transition that latter operation also returns
> ['abc'] in the long run, could be to have an explicit split operator as
> recommended use, e.g.,
>
> 'abc'.split()
> 'abc'.split('')
> 'abc'.chars()
> 'abc'.items()
>
> the latter two could return an iterator whereas the former two return lists
> (currently raise exceptions).
> Similar for bytes, etc.
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
