I feel like that argument is flawed. I cannot think of another good example (I am sure there are plenty!) but there is a big difference for discoverability between:

A function that does something *different* and functionality does not exist in a built-in (or whatever namespace you are considering). For example, zip_longest v.s. zip: if you have know/expect one of your iterators to run out early, but do not wish the zipping to end, normal zip won't do and so you will end up searching for an alternative.

A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus zip-with-strict-true.

I did not phrase that particularly well, but I am hoping people get the gist/can rephrase it better.

On Tue, 5 May 2020 at 11:34, Paul Moore <p.f.moore@gmail.com> wrote:
On Tue, 5 May 2020 at 07:22, Christopher Barker <pythonchb@gmail.com> wrote:

> In any case, you seem to making the argument that a few of us are putting forward: yes, a flag on zip() is likely to get more use than a function in itertools. Thanks for the support :-)

I'd like to add my voice to the people saying that if someone isn't
willing to go and find the correct function, and import it from the
correct module, to implement the behaviour that they want, then I have
no interest in making it easier for them to write their code
correctly, because they seem to have very little interest in
correctness. Can someone come up with any sort of credible argument
that someone who's trying to write their code correctly would be in
any way inconvenienced by having to get the functionality from
itertools?

It seems like we're trying to design a way for people to
"accidentally" write correct code without trying to, and without
understanding what could go wrong if they use the current zip
function. I'm OK with "make it easy to do the right thing", but "make
it easy to do the right thing by accident" is a step too far IMO.

Paul
_______________________________________________
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/E3C4GFR6XVFJFOPTKQX4VI647HHBJVYC/
Code of Conduct: http://python.org/psf/codeofconduct/