Here's an idea for combining zip_longest with zip strict. Define zip like so:

def zip(*iterables, strict=False, fill=object())

With no arguments, it's the regular old zip. With `strict=True`, it ensures the iterators are equal. If you pass in an argument for `fill`, it becomes zip_longest.

On Sun, Apr 26, 2020 at 7:37 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Sat, Apr 25, 2020 at 10:50 AM Kirill Balunov <kirillbalunov@gmail.com> wrote:
  ...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







 
--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/4EHYHP3XGPU2XJA4AC6PMNVMMWEI5PXD/
Code of Conduct: http://python.org/psf/codeofconduct/