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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/2W5GF37T3T6XABYU6G5LOHUEJFLIGIBT/
Code of Conduct: http://python.org/psf/codeofconduct/
