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