Re: [Python-ideas] discontinue iterable strings

[Alexander Heger]

On 20 August 2016 at 15:47, Franklin? Lee 
wrote:
On Aug 19, 2016 11:14 PM, "Alexander Heger"  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.

I'm bothered by it whenever I want to write code that takes a sequence and
returns a sequence of the same type.

But I don't think that the answer is to remove the concept of strings as
sequences. And I don't want strings to be sequences of character code
points, because that's forcing humans to think on the implementation level.

Please explain the problem with the status quo, preferably with examples
where it goes wrong.

> For example, numpy has no issues
>
> >>> np.array('abc')
> array('abc', dtype='>> a = np.array('abc')
>>> a[()]
'abc'
>>> a[()][2]
'c'

The point is it does not try to disassemble it into elements as it would do
with other iterables

>>> np.array([1,2,3])
array([1, 2, 3])
>>> np.array([1,2,3]).shape
(3,)

Numpy is for numbers. It was designed with numbers in mind. Numpy's
relevant experience here is wy less than general Python's.

But it does deal with strings as monolithic objects, doing away with many
of the pitfalls of strings in Python.
And yes, it does a lot about memory management, so it is fully aware of
strings and bytes ...
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Brendan Barnwell]

On 2016-08-19 13:11, C Anthony Risinger wrote:

It might be harder to find the end of an f-string in one shot, but I
think that's the crux of the issue: to a reader/developer, is an
f-string conceptually one thing or a compound thing?

To me (someone who would like to see f-string expressions appear like
normal expressions, without extra quoting, and proper syntax
highlighting *always*, just like shell), this argument is essentially
the same as trying to use a regex to find a closing bracket or brace or
parse HTML. It's only hard (disregarding any underlying impl details)
because that view regards f-strings as singular things with only one
"end", when in reality an f-string is much much more like a compound
expression that just happens to look like a string.


	Personally I think that is a dangerous road to go down.  It seems it 
would lead to the practice of doing all sorts of complicated things 
inside f-strings, which seems like a bad idea to me.  In principle you 
could write your entire program in an f-string, but that doesn't mean we 
need to accommodate the sort of syntax highlighting that would 
facilitate that.


	To me it seems more prudent to just say that f-strings are (as the name 
implies) strings, and leave it at that.  If I ever get to the point 
where what I'm doing in the f-string is so complicated that I really 
need syntax highlighting for it to look good, I'd take that as a sign 
that I should move some of that code out of the f-string into ordinary 
expressions.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Brendan Barnwell]

On 2016-08-19 20:57, C Anthony Risinger wrote:

In a quality editor, everything about the {...} will tell me I'm writing a
Python expression. It'll be colored like an expression. It'll do fancy
completion like an expression. Aw shucks, it*IS*  a Python expression!
Except for one tiny detail: I'm not allowed to use the quote I use in 95%
of all my Python code--without thinking--because I already used it at the
string start :-( It's like this weird invisible ruh-roh-still-in-a-string
state hangs over you despite everything else suggesting otherwise


	But it IS inside a string.  That's why it's an f-string.  The essence 
of your argument seems to be that you want expressions inside f-strings 
to act just like expressions outside of f-strings.  But there's already 
a way to do that: just write the expression outside of the f-string. 
Then you can assign it to a variable, and refer to the variable in the 
f-string.  The whole point of f-strings is that they allow expressions 
*inside strings*.  It doesn't make sense to pretend those expressions 
are not inside strings.  It's true that the string itself "isn't really 
a string" in the sense that it's put together at runtime rather than 
being a constant, but again, the point of f-strings is to make things 
like that writable as strings in source code.  If you don't want to 
write them as strings, you can still concatenate separate string values 
or use various other solutions.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Alexander Heger]

>
> > That says, "This is a 0-length array of 3-char Unicode strings." Numpy
> > doesn't recognize the string as a specification of an array. Try
> > `np.array(4.)` and you'll get (IIRC) `array(4., dtype='float')`, which
> > has
> > shape `()`. Numpy probably won't let you index either one. What can you
> > even do with it?
>
> In my poking around I found that you can index it with [()] or access
> with .item() and .itemset(value). Still seems more like a party trick
> than the well-reasoned practical implementation choice he implied it
> was.


my apologies about the confusion, the dim=() was not the point, but rather
that numpy treats the string as a monolithic object rather than
disassembling it as it would do with other iterables.  I was just trying to
give the simplest possible example.

Numpy still does

>>> np.array([[1,2],[3,4]])
array([[1, 2],
   [3, 4]])
>>> np.array([[1,2],[3,4]]).shape
(2, 2)

but not here

>>> np.array(['ab','cd'])
array(['ab', 'cd'],
  dtype='>> np.array(['ab','cd']).shape
(2,)

-Alexander
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Chris Angelico]

On Sat, Aug 20, 2016 at 4:28 PM, Alexander Heger  wrote:
> Yes, I am aware it will cause a lot of backward incompatibilities...

Tell me, would you retain the ability to subscript a string to get its
characters?

>>> "asdf"[0]
'a'

If not, you break a ton of code. If you do, they are automatically
iterable *by definition*. Watch:

class IsThisIterable:
def __getitem__(self, idx):
if idx < 5: return idx*idx
raise IndexError

>>> iti = IsThisIterable()
>>> for x in iti: print(x)
...
0
1
4
9
16

So you can't lose iteration without also losing subscripting.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Alexander Heger]

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  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  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=' >
> > 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/

Re: [Python-ideas] discontinue iterable strings

[Franklin? Lee]

On Aug 20, 2016 2:27 AM, "Alexander Heger"  wrote:
> The point is it does not try to disassemble it into elements as it would
do with other iterables
>
> >>> np.array([1,2,3])
> array([1, 2, 3])
> >>> np.array([1,2,3]).shape
> (3,)

It isn't so much that strings are special, it's that lists and tuples are
special. Very few iterables can be directly converted to Numpy arrays. Try
`np.array({1,2})` and you get `array({1, 2}, dtype=object)`, a
0-dimensional array.

> But it does deal with strings as monolithic objects,

Seems to me that Numpy treats strings as "I, uh, don't really know what you
want me to do with this" objects. That kinda makes sense for Numpy,
because, uh, what DO you want Numpy to do with strings?

Numpy is NOT designed to mess around with strings, and Numpy does NOT have
as high a proportion of programmers using it for strings, so Numpy does not
have much insight into what's good and what's useful for programmers who
need to mess around with strings.

In summary, Numpy isn't a good example of "strings done right, through more
experience", because they are barely "done" at all.

> doing away with many of the pitfalls of strings in Python.

Please start listing the pitfalls, and show how alternatives will be an
improvement.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Stephen J. Turnbull]

C Anthony Risinger writes:

 > The only time I personally use a different quote is when it somehow
 > makes the data more amenable to the task at hand. The data! The
 > literal data! Not the expressions I'm conveniently inlining with
 > the help of f-strings.

You do *not* know that yet!  *Nobody* does.  Nobody has yet written an
f-string in production code, let alone read thousands and written
hundreds.  Can you be sure that after you write a couple dozen
f-strings you won't find that such "quote context" is carried over
naturally from the way you write other strings?  (Eg, because "I'm
still in a string" is signaled by the highlighting of the surrounding
stringish text.)

I think the proposed changes to the PEP fall into the "Sometimes never
is better than *right* now" category.  The arguments I've seen so far
are plausible but not founded in experience: it could easily go the
other way, and I don't see potential for true disaster.

 > If I have to water it down for people to find it acceptable (such
 > as creating simpler variables ahead-of-time) I'd probably just keep
 > using .format(...). Because what I have gained with an f-string?

I don't see a problem if you choose not to write f-strings.  Would
other people using that convention be hard for you to *read*?

 > Not just because it's at odds with other languages, but because
 > it's at odds with what the editor is telling the user (free-form
 > expression).

There are no editors that will tell you such a thing yet.

And if you trust an editor that *does* tell you that it's a free-form
expression and use the same kind of quote that delimits the f-string,
you won't actually create a syntax error.  You're merely subject to
the same kind of "problem" that you have if you don't write PEP8
conforming code.

Regards,

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Paul Moore]

On 20 August 2016 at 04:57, C Anthony Risinger  wrote:
> The two string parts are string-colored and the x.partition bits would look 
> like
> any other code in the file. It won't look like concatenation at that point.

That's entirely subjective and theoretical (unless you've implemented
it and reviewed the resulting look of the code). In my (equally
subjective and theoretical) opinion it would still look like
concatenation, and would confuse me. I made a deliberate point of
saying that *to me* it looked like concatenation.

YMMV - remember this tangent was started by people stating their
opinions. Saying that your opinion differs doesn't invalidate their
(my) view.

> tl;dr, UX is weaker when the editor implies a free-form expression in every
> possible way, but the writer can't use the quote they always use, and I
> think strings will be common in f-string expression sections.

FWIW I would instantly reject any code passed to me for review which
used the same quote within an f-string as was used to delimit it,
should this proposal be accepted.

Also, a lot of code is read on media that doesn't do syntax
highlighting - email, books, etc. A construct that needs syntax
highlighting to be readable is problematic because of this.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Random832]

On Sat, Aug 20, 2016, at 01:47, Franklin? Lee wrote:
> That says, "This is a 0-length array of 3-char Unicode strings." Numpy
> doesn't recognize the string as a specification of an array. Try
> `np.array(4.)` and you'll get (IIRC) `array(4., dtype='float')`, which
> has
> shape `()`. Numpy probably won't let you index either one. What can you
> even do with it?

In my poking around I found that you can index it with [()] or access
with .item() and .itemset(value). Still seems more like a party trick
than the well-reasoned practical implementation choice he implied it
was.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Michael Selik]

On Sat, Aug 20, 2016 at 3:48 AM Chris Angelico  wrote:

> On Sat, Aug 20, 2016 at 4:28 PM, Alexander Heger  wrote:
> > Yes, I am aware it will cause a lot of backward incompatibilities...
>
> Tell me, would you retain the ability to subscript a string to get its
> characters?
>
> >>> "asdf"[0]
> 'a'
>

A separate character type would solve that issue. While Alexander Heger was
advocating for a "monolithic object," and may in fact not want
subscripting, I think he's more frustrated by the fact that iterating over
a string gives other strings. If instead a 1-length string were a
different, non-iterable type, that might avoid some problems.

However, special-casing a character as a different type would bring its own
problems. Note the annoyance of iterating over bytes and getting integers.

In case it's not clear, I should add that I disagree with this proposal and
do not want any change to 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/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Eric V. Smith]

On 8/19/2016 2:57 PM, Guido van Rossum wrote:

I don't think we should take action now.

Would it make sense, as a precaution, to declare the PEP provisional for
one release? Then we can develop a sense of whether the current approach
causes real problems.

We could also emit some kind of warning if the expression part contains
an escaped quote, since that's where a potential change would cause
breakage. (Or we could leave that to the linters.)


If anything, I'd make it an error to have any backslashes inside the 
brackets of an f-string for 3.6. We could always remove this restriction 
at a later date.


I say this because as soon as f-strings make it into the wild, we're 
going to have a hard time breaking code in say 3.7 by saying "well, we 
told you that f-strings might change".


Although frankly, other than be executive fiat (which I'm okay with), I 
don't see us ever resolving the issue if f-strings are strings first, or 
if the brackets put you into "non-string mode". There are good arguments 
on both sides.


Moving to the implementation details, I'm not sure how easy it would be 
to even find backslashes, though. IIRC, backslashes are replaced early, 
before the f-string parser really gets to process the string. It might 
require a new implementation of the f-string parser independent of 
regular strings, which I likely would not have time for before beta 1. 
Although since this would be a reduction in functionality, maybe it 
doesn't have to get done by then.


I also haven't thought of how this would affect raw f-strings.

In any event, I'll take a look at adding this restriction, just to get 
an estimate of the magnitude of work involved. The easiest thing to do 
might be to disallow backslashes in any part of an f-string for 3.6, 
although that seems to be going too far.


Eric.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Michael Selik]

On Sat, Aug 20, 2016 at 4:57 PM Alexander Heger  wrote:

> 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. 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

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?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Alexander Heger]

>
> 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/

Re: [Python-ideas] discontinue iterable strings

[אלעזר]

On Sun, Aug 21, 2016 at 12:28 AM Alexander Heger  wrote:

> 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__`.
>
>  Is there any equivalent __future__ import with such deep semantic
implications? Most imports I can think of are mainly syntactic.
And what would it do? change the type of string literals? change the
behavior of str methods locally in this module? globally? How will this
play with 3rd party libraries?
Sounds like it will break stuff in a way that cannot be locally fixed.

~Elazar
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Nick Coghlan]

On 21 August 2016 at 15:22, Nick Coghlan  wrote:
> There may also be a case to be made for introducing an AtomicStr type
> into Python's data model that works like a normal string, but
> *doesn't* support indexing, slicing, or iteration, and is instead an
> opaque blob of data that nevertheless supports all the other usual
> string operations. (Similar to the way that types.MappingProxyType
> lets you provide a read-only view of an otherwise mutable mapping, and
> that collections.KeysView, ValuesView and ItemsView provide different
> interfaces for a common underlying mapping)

Huh, prompted by Brendan Barnwell's comment, I just realised that a
discussion I was having with Graham Dumpleton at PyCon Australia about
getting the wrapt module (or equivalent functionality) into Python 3.7
(not 3.6 just due to the respective timelines) is actually relevant
here: given wrapt.ObjectProxy (see
http://wrapt.readthedocs.io/en/latest/wrappers.html#object-proxy ) it
shouldn't actually be that difficult to write an "atomic_proxy"
implementation that wraps arbitrary container objects in a proxy that
permits most operations, but actively *prevents* them from being
treated as collections.abc.Container instances of any kind.

So if folks are looking for a way to resolve the perennial problem of
"How do I tell container processing algorithms to treat *this
particular container* as an opaque blob?" that arise most often with
strings and binary data, I'd highly recommend that as a potentially
fruitful avenue to start exploring.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] discontinue iterable strings

[Chris Angelico]

On Sun, Aug 21, 2016 at 12:52 PM, Steven D'Aprano  wrote:
>> > The fixes overall will be a lot easier and obvious than introduction of
>> > unicode as default string type in Python 3.0.
>>
>> That's a bold claim. Have you considered what's at stake if that's not true?
>
> Saying that these so-called "fixes" (we haven't established yet that
> Python's string behaviour is a bug that need fixing) will be easier and
> more obvious than the change to Unicode is not that bold a claim. Pretty
> much everything is easier and more obvious than changing to Unicode. :-)
> (Possibly not bringing peace to the Middle East.)

And yet it's so simple. We can teach novice programmers about two's
complement [1] representations of integers, and they have no trouble
comprehending that the abstract concept of "integer" is different from
the concrete representation in memory. We can teach intermediate
programmers how hash tables work, and how to improve their performance
on CPUs with 64-byte cache lines - again, there's no comprehension
barrier between "mapping from key to value" and "puddle of bytes in
memory that represent that mapping". But so many programmers are
entrenched in the thinking that a byte IS a character.

> 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]. IMO the second option is a
total non-flyer - good luck convincing anyone that THAT is an
improvement. The first one is possible, but dramatically broadens the
backward-compatibility issue. You'd have to search for any class that
defines __getitem__ and not __iter__.

If that *does* get considered, it wouldn't be too hard to have a
compatibility function, maybe in itertools.

def subscript(self):
i = 0
try:
while "moar indexing":
yield self[i]
i += 1
except IndexError:
pass

class Demo:
def __getitem__(self, item):
...
__iter__ = itertools.subscript

But there'd have to be the full search of "what will this break", even
before getting as far as making strings non-iterable.

ChrisA

[1] Not "two's compliment", although I'm told that Two can say some
very nice things.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/