On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano, <st...@pearwood.info> wrote:
> > > > 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. > Given that the only input parameters are the iterables themselves, it's a stretch to even consider the first two as possibilities. > 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. > "strict=False" doesn't tell you whether the tolerant behaviour is truncation or padding. "truncate=True" does. > For the default case, strict=False and truncate=True are pretty much > equal in information. > Nope. If you don't already know that zip truncates the output by default, "truncate=True" gives you that information, while "strict=False" doesn't. > 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. > But raise an exception when? In the context of this discussion, we know we mean "strict length checking, raising an exception for inconsistent lengths". But "strict" on its own doesn't convey that - we could be requesting strict runtime type checking, for example, where each iterable is expected to keep producing items of the same type as was produced for the first tuple. Or we could be requesting a check that the values in the tuple aren't "None". > > 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). > As noted above, "strict" just means "check more constraints" - it's at least as ambiguous as "don't truncate the output". I do agree that the ambiguity of "truncate=False" is the biggest downside of that spelling, but learning that it means "raise an exception on a length mismatch instead of truncating the output iterator" isn't going to be any harder than learning what strict mode means. Cheers, Nick. > > > > -- > 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/ >
_______________________________________________ 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/NAHKEDDJGWRFL5S6FNWMYLKK7PYY4XGW/ Code of Conduct: http://python.org/psf/codeofconduct/
