Christopher's quoting is kinda messed up and I can't be bothered fixing
it, sorry, so you'll just have to guess who said what :-)
On Tue, May 05, 2020 at 01:03:30PM -0700, Christopher Barker wrote:
> "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.
I didn't say a *new* builtin. You are talking about having this
related but distinct functionality piggy-back on top of the
existing tolerant zip function, distinguishing them by a flag.
I trust you wouldn't try to argue that `int(string, base)` is not
a builtin function? :-)
> > 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.
Okay, but a function in the std lib is sufficient for that. If you want
to argue against the alternatives:
- use more-itertools
- make it a recipe in the docs
then "more people will use it" is a good argument for putting it into
the stdlib. But why should we fear that there will be people doing
without, or rolling their own, because it's not builtin?
`zip_longest` has been in the stdlib for at least a decade. We know it
has use-cases, and unlike this strict version of zip the need for this
was established and proven long ago. If there are people doing without,
or rolling their own, zip_longest because they either don't know about,
or cannot be bothered, importing from itertools, should it be in
builtins too?
> > 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!
A ternary flag of strict = True, False or what?
This demonstrates why the "constant flag" is so often an antipattern. It
doesn't scale past two behaviours. Or you end up with a series of flags:
zip(*iterators, strict=False, longest=False, fillvalue=None)
and then you have to check for incompatible combinations:
if longest and strict:
raise TypeError('cannot combine these two options')
and it becomes worse the more flags you have.
Or you end up with deprecated parameters:
def zip(*iterators, strict=_sentinel, mode=ZIP_MODES.SHORTEST):
if strict is not _sentinel:
raise DeprecationWarning
> But if we did, then would it be better to have eight separate functions in
> itertools?
You wouldn't have eight separate functions. You would have four. But to
distinguish four independent modes in a single function, you need three
flags, and that gives you 2**3 = 8 combinations to deal with, all of
which have to be checked, and exceptions raised if the combination is
invalid.
--
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/UANJQXQNWQY2C6ADLJO3P2PJ44Q37RGD/
Code of Conduct: http://python.org/psf/codeofconduct/
