"If its builtin people will be more likely to use it, so we need to make
> it builtin." > > This argument will apply to **literally** every function and class in > the standard library. But we are not talking adding a new builtin. > Firstly, we would have to agree that "maximizing the number of people > using the strict version of zip" is our goal. I don't think it is. Neither do I. But I am suggesting that "maximizing the number of people that need a strict version of zip will use it" Rather than, say, checking the length of the inputs before calling zip. Or writing their own version. Think about the strange discrepency between the three (so far...) kinds > of zip: > > - zip (shortest) is builtin, controlled by a flag; > - zip strict is builtin, controlled by a flag; > - zip longest is in a module, with a distinct name. > > Why is zip_longest different? What if we want to add a fourth or fifth > flavour of zip? Do we then have three flags on zip and have to deal with > eight combinations of them? > no -- but we could (and I think should) have a ternary flag, so that zip_longest becomes unnecessary. And we'd never get to eight combinations: you can't have longest and shortest behavior at the same time! But if we did, then would it be better to have eight separate functions in itertools? -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/FWZU546YMOYHGCXFYESZZCITV5LURR6R/ Code of Conduct: http://python.org/psf/codeofconduct/
