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 <guido@python.org> wrote:
On Mon, Jul 25, 2016 at 10:19 AM, Gregory P. Smith <greg@krypto.org> 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.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/