On Sat, Apr 25, 2020 at 10:50 AM Kirill Balunov <[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/4EHYHP3XGPU2XJA4AC6PMNVMMWEI5PXD/
Code of Conduct: http://python.org/psf/codeofconduct/
