On Tue, Jun 02, 2020 at 08:52:46PM +1000, Nick Coghlan wrote: > > 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.
And then: > "strict=False" doesn't tell you whether the tolerant behaviour is > truncation or padding. "truncate=True" does. You can't have it both ways Nick -- if the lack of additional parameters is enough for the user to predict that the only reasonable behaviour is to truncate, then the lack of additional parameters is also enough for them to predict that the only reasonable non-strict (tolerant) behaviour is to truncate at the shortest input. [...] > > 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". If you are going to propose that users might imagine a hypothetical check that raises if any item is None, well, isn't that *precisely* the sentinel check I gave above that you blithly dismissed as "a stretch"? If it's a stretch for me, it's a stretch for you too. Ultimately, bikeshedding on the name truncate versus strict versus equal versus shortest versus ... is quibbling. Everyone who reads the tooltips, assuming they even see them, is going to take something different from it. Some will think "truncate what, the tuples?" and some will think "strict about what?". Ultimately the tooltips are no substitute for reading the docs. If you don't know what zip does, you cannot interpret what it means for zip to truncate or be strict. No one single word is going to communicate everything we need to communicate. Function and parameter names are mnemonics, not documentation. So on that note, and in regard only to the choice between "strict" versus "truncate" etc, I'm going to bow out: call it what you will. I've got a bigger problem with the use of a boolean flag than the name. -- 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/OP735VEXJMXWIEMS5OTHQMH2IQXOK4YO/ Code of Conduct: http://python.org/psf/codeofconduct/
