...the mode switching approach in the current situation looks reasonable, because the question is how boundary conditions should be treated. I still prefer three cases switch like `zip(..., mode=('equal' | 'shortest' | 'longest'))`
I like this -- it certainly makes a lot more sense than having zip(), zip(...,strict=True), and zip_longest()
So I'm proposing that we have three options on the table:
zip(..., mode=('equal' | 'shortest' | 'longest'))
or
zip()
zip_longest()
zip(equal)
or, of course, keep it as it is.
... but also ok with `strict=True` variant.
Chris Angelico wrote:
Separate functions mean you can easily and simply make a per-module decision:
from itertools import zip_strict as zip
Tada! Now this module treats zip as strict mode.
this is a nifty feature of multiple functions in general, but I'm having a really hard time coming up with a use case for these particular functions: you're using zip() multiple times in one module, and you want them all to be the same "version", but yiou want to be able to easily change that version on a module-wide bases?
As for the string methods examples: one big difference is that the string methods are all in the same namespace. This is different because zip() is a built in, but zip_longest() and zip_equal() would not be. I don't think anyone is suggesting adding both of those to builtins. So adding a mode switch is the only way to "unify" them -- maybe not a huge deal, but I think a big enough deal that zip_equal wouldn't see much use.
>and changing map and friends to iterators is a big part of why you can
write all kinds of things naturally in Python 3.9 that were clumsy,
complicated, or even impossible.
Sure, and I think we're all happy about that, but I also find that we've lost a bit of the nice "sequence-oriented" behavior too. Not sure that's relevant to this discussion though. Bu tit is on one way:Back in 1.5 days, you would always use zip() on sequences, so checking their length was trivial, if you really wanted to do that -- but while checking that your iterators were in fact that same length is possible, it's pretty klunky, and certainly not newbie-friendly.
I've lot track of who said it, but I think someone proposed that most people really want zip_longest most often. (sorry if I'm misinterpreting that). I think this is kinda true, in the sense that if you only had one, than zip_longest would be able to conver teh most use-cases (you can build a zip_shortest out of zip_longest, but not the other way around) but particularly as zip_longest() is going to fail with infinite iterators, it can't be the only option after all.
One other comment about the modes vs multiple functions:
It makes a difference with implementation -- with multiple functions, you have to re-implement the core functionality three times (DRY) -- or have a hidden common function underneath -- that seems like code-smell to me.
-CHB