On Mon, Jun 01, 2020 at 09:36:40PM +1000, Nick Coghlan wrote: > zip() can be used to combine iterables of different lengths, including > combining finite iterables with infinite iterators. By default, the output > iterator is implicitly truncated to produce the same number of items as the > shortest input iterable. Setting *truncate* to false disables this implicit > truncation and raises ValueError instead.
It's not really *implicit* if there's an explicit flag controlling the behaviour, even with a default value. We don't use that sort of language elsewhere. For example, help(sorted) doesn't say: "Return a new list containing all items from the iterable implicitly in ascending order. Pass reverse=True to disable this implicit order." help(int) doesn't say that the base is implicitly decimal; help(print) doesn't talk about "implicit spaces between items, implicit newline at the end of the output" etc. It just states the behaviour controlled by the parameter. This is accurate, non-judgemental, and avoids being over-wordy: "By default, the output iterator is truncated at the shortest input iterable." > The conceptual idea here is that the "truncate" flag name would technically > be a shorter mnemonic for "truncate_silently", so clearing it gives you an > exception rather enabling padding behaviour. > > Flipping the sense of the flag also means that "truncate=True" will appear > in IDE tooltips as part of the function signature, providing significantly > more information than "strict=False" would. "Significantly" more? I don't think so. Truncate at what? - some maximum length; - some specific element; - at the shortest input. At some point people have to read the docs, not just the tooltips. If you didn't know what zip does, seeing truncate=True won't mean anything to you. If you do know what zip does, then the parameter names are mnemonics, and strict=False and truncate=True provide an equal hint for the default behaviour: * if it's not strict, it is tolerant, stopping at the shortest; * if it truncates, it truncates at the shortest input. For the default case, strict=False and truncate=True are pretty much equal in information. But for the case of non-default behaviour, strict=True is a clear winner. It can pretty much only mean one thing: raise an exception. Whereas truncate=False is ambiguous: - pad the output; - skip items as they become empty; - raise an exception. All three of these are useful behaviour, and while the middle one is not part of this PEP, it was requested in the discussions on Python-Ideas. > That improved self-documentation then becomes what I would consider the > strongest argument in favour of the flag-based approach: I don't think that "truncate=False" (which can mean three different things) is more self-documenting than `zip(*items, mode='strict')` or `zip_strict()` (either of which can only mean one thing). -- Steven _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/37TI3ZEU7JZUJBERFDRRCMNI5Y3CGP7T/ Code of Conduct: http://python.org/psf/codeofconduct/
