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.
you can always define __len__ and __index__ independently. I do this for
many objects. But it is a point I have not considered.
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?)
Yes, I am aware it will cause a lot of backward incompatibilities, but this
is based on all the lengthy discussions about "string but not iterable"
type determinations. If sting was not iterable, a lot of things would also
be easier. You could also argue why an integer cannot be iterated over its
bits?
As had been noted, is one of few objects of which the component can be the
object itself. 'a'[0] == 'a'
I do not iterate over strings so often that it could not be done using,
e.g., str.chars():
for c in str.chars():
print(c)
On 20 August 2016 at 13:24, Edward Minnix <egregius...@gmail.com> wrote:
> 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/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
