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

Reply via email to