On Wed, May 06, 2020 at 08:48:51AM -0700, Christopher Barker wrote: [I asked] > > A ternary flag of strict = True, False or what? > > > > Come on: > > ternary: having three elements, parts, or divisions ( > https://www.merriam-webster.com/dictionary/ternary) > > did you really not know that?
Of course I know what ternary is. > (and "flag" does not always mean "boolean > flag", even thoughit often does (https://techterms.com/definition/flag) ) I am arguing against the proposal being discussed in this part of the thread, namely to add a **boolean** flag "strict=True|False". Then if we want to extend the API in the future, you say "Oh well that's easy, let's just turn it into a ternary flag" (paraphrasing, not a direct quote). Okay, so what will the third flag be? Standard ternary flags are: True, False, Maybe True, False, Unknown Neither Maybe nor Unknown are Python builtins. Should they be? I doubt it. So what do we use? Whenever I've needed ternary logic, I've used None. But in this case, that doesn't work: zip(*iters, strict=None) What a very non-self-explanatory API. So if we start off with a `strict=bool` API, we're stuck with it. > This has been proposed multiple times on this list: > > a flag that takes three possible values: "shortest" | "longest" | "equal" > (defaulting to shortest of course). Name to be bikeshed later :-) > (and enum vs string also to be bikeshed later) *Named modes* are not typically called flags. For example, the second parameter to `open` is called *mode*, not *flag*. Whether or not a named mode parameter has been proposed before, that's not what is being discussed here and now, where we have been explicitly debating the two APIs: - a named function; - piggy-backing on zip() with a **boolean parameter** taking True and False as the switch to control behaviour. so in the context of the discussion about bool parameters, other APIs aren't really relevant. I'm arguing agains the specific `strict=bool` API, not other APIs in general. Revamping zip to give it a named mode parameter is not my first preference, but it's better than a `strict=bool` flag. However the parameter would have to change: zip(*iters, strict="shortest") simply doesn't work. > > This demonstrates why the "constant flag" is so often an > > antipattern. It doesn't scale past two behaviours. Or you end up > > with a series of flags: > > > > zip(*iterators, strict=False, longest=False, fillvalue=None) > > > > I don't think anyone proposed an API like that -- yes, that would be horrid. I do recall someone proposing something similar to that, but I don't care enough to trawl through the thread to find it :-) > There are all sorts of reasons why a ternary flag would not be good, but I > do think it should be mentioned in the PEP, even if only as a rejected idea. > > But I still like it, 'cause the "flag for two behaviors and another > function for the third" seem sliek the worse of all options. *blink* But that's precisely the option on the table right now! 1. zip_longest remains in itertools; 2. zip remains the default behaviour; 3. zip_strict be implemented as a boolean True/False parameter on zip. I trust you don't actually mean what you seem to be saying: "this is the worst of all options, I'm in favour of it!" But in any case, I see from a later part of the discussion we're now considering a different option: - treat zip as a namespace, with named callable attributes which I don't dislike. -- Steven _______________________________________________ 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/MEY2FNXI6NDAOIQLI7KGE7LR5A5GSANH/ Code of Conduct: http://python.org/psf/codeofconduct/
