I'm sorry, I was using Socratic questions to get people to think mount about the name and semantics for this one type. I certainly don't think we should have more of these! At least not until we've added an "except" type to PEP 484. On Mon, Jul 25, 2016 at 2:29 PM, Bar Harel <bzvi7919@gmail.com> wrote:
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/
-- --Guido van Rossum (python.org/~guido)