On Tue, May 05, 2020 at 05:28:08PM +0100, Henk-Jaap Wagenaar wrote:
But you care about your input, you can do so by setting strict=True (if that's the road we go down), and unlike what others have said, the IDE I use (pycharm) would tell me that flag exists as I type "zip" and so I'd be more likely to use it than if it was in itertools/...
We keep coming to this same old argument over and over. "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. Pick any arbitrary module, any function from that module: `imghdr.what`. I literally didn't even know that function existed until 30 seconds ago. If it had been a builtin, I would have known about it years ago, and would have been more likely to use it. All this is true. But it's not an argument in favour of making it a builtin. (Or at least not a *good* argument.) 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. We don't try to maximize the number of people using `imghdr.what` -- it is there for those who need it, but we're not trying to push people to use it whether they need it or not. And secondly, that assumes that the benefit gained is greater than the cost in making the builtins more complicated. It now has two functions with the same name, `zip`, distinguished by a runtime flag, even though that flag will nearly always be given as a compile-time constant: # Almost always specified as a compile-time constant: zip(..., strict=True) # Almost never as a runtime variable: flag = settings['zip'].tolerant zip(..., strict=not flag) That "compile-time constant" suggests that, absent some compelling reason, the two functions ought to be split into separate named functions. "But my IDE..." is not a compelling reason. This is not a hard law, but it is a strong principle. Compile-time constants to swap from two distinct modes often make for poor APIs, and we should be reluctant to design our functions that way if we can avoid it. (Sometimes we can't -- but this is not one of those times.) 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? -- Steven