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