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 <python...@gmail.com>
wrote:
> On Sat, Apr 25, 2020 at 10:50 AM Kirill Balunov <kirillbalu...@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-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/4EHYHP3XGPU2XJA4AC6PMNVMMWEI5PXD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/BQYG3NHQXAQBREIWULJFWNQQXQR6NQZE/
Code of Conduct: http://python.org/psf/codeofconduct/
