Christopher's quoting is kinda messed up and I can't be bothered fixing
it, sorry, so you'll just have to guess who said what :-)
Ideally, we are evaluating ideas independently of who expressed them, so I'll pretend I did that on purpose :-)
First: really people, it's all been said. I think we all (and I DO include myself in that) have fallen into the trap that "if folks don't agree with me, I must not have explained myself well enough" -- but in this case, we actually do disagree. And not really on the facts, just on the relative importance.
But since, I apparently did not explain myself well enough in this case:
> no -- but we could (and I think should) have a ternary flag, so that
> zip_longest becomes unnecessary. And we'd never get to eight combinations:
> you can't have longest and shortest behavior at the same time!
A ternary flag of strict = True, False or what?
Come on:
(by the way, I'm posting those references because I looked them up to make sure I wasn't using terms incorrectly)
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)
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.
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.
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython