We really do a need a FAITHBR (Frequently Asked Ideas that Have Been Rejected) somewhere …
But anyway, I’m not supportive of this idea, but I don’t think this logic holds:
Back in the day, Python was all about Sequences – or maybe Collections. But modern Python is more about Iterables.
for _ in is a way to iterate, that requires an iterable.
in by itself invokes __contains__ – and is about inclusion in a collection.
They use the same word, and there is often a parallel, but that doesn’t mean that there has to be – there are any number of iterables that are not containers. There is nothing surprising about that.
In fact, I wonder if the range object would be a container if it hadn’t evolved from the original range() that created a realized list. Does it get used that way often? (not in my code).
I still don’t think it’s a good idea for the other reasons posted in this thread, but the idea that anything iterable should be container is not compelling to me.
NOTE: If an object is both an iterable and a container, then yes, there should be symmetry – e.g. what dicts do: using the keys for iteration and contains.