> > IIRC, the new unpacking code still works like the old in that it > special-cases list and tuple (where it can use the fast indexing API that > just accesses the C array underneath), but for everything else it calls a > function with iter(obj). If so, adding the length for list and tuple would > be trivial, but adding it for other builtin types would not. >
Seems you're right: https://github.com/python/cpython/blob/baf29b221682be0f4fde53a05ea3f57c3c79f431/Python/ceval.c#L2243-L2252 > Is list and tuple good enough? It won’t help your example use, where it’s > str, but I think for that case you don’t generally care that the string had > 6 chars instead of 2; you already know the problem from it being a string > in the first place. I suspect that almost every time the type is right but > the length isn’t, the type is list, tuple, or a non-builtin type. How often > do you accidentally unpack a length-6 dict where you wanted to unpack a > length-2 dict? > I agree with all of this, and I think this is a great balance of implementation complexity and value, especially when the code already accounts for it. I've made an issue here: https://bugs.python.org/issue39816?
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BQEBVV6YBGIRP3YM4U2SPG6W5YOM4FFL/ Code of Conduct: http://python.org/psf/codeofconduct/
