Guido, I'm not entirely sure if you're joking or not, but if we'll start with this, we will never finish.

I believe that although str/bytes truly are special regarding iterables, the combinations are endless.
Soon enough we'll have NotBytesSequence, NumericSequenceWithoutFloat and BuiltinNotCustomMadeIterable.

We cannot guarantee a "meaning". We can however guarantee an interface or API, in this case __iter__,
and promote duck-typing in order to support even the craziest custom iterables.

I think breaking the design or the state-of-mind in case of "IterableButNotString" would be a mistake, unless
we're planning to remove str's __iter__ altogether (which I don't support either but who knows).

Nevertheless, +1 for the unification of Iterable, Sized and Container or "Reiterables" as it declares a clearer interface.

On Mon, Jul 25, 2016 at 9:03 PM Guido van Rossum <> wrote:
On Mon, Jul 25, 2016 at 10:19 AM, Gregory P. Smith <> wrote:
> Given how often the str problem comes up in this context, I'm thinking a
> common special case in type annotation checkers that explicitly exclude str
> from consideration for iteration.  It's behavior is rarely what the
> programmer intended and more likely to be a bug.

Should we have IterableButNotString, CollectionExceptString,
NonStringSequence, or all three? I suppose the runtime check would be
e.g. isinstance(x, Iterable) and not isinstance(x, (str, bytes,
bytearray, memoryview))? And the type checker should special-case the
snot out of it?

--Guido van Rossum (
Python-ideas mailing list
Code of Conduct: