> On May 9, 2020, at 04:30, Alex Hall <alex.moj...@gmail.com> wrote: > >> On Fri, May 8, 2020 at 11:22 PM Andrew Barnert via Python-ideas >> <python-ideas@python.org> wrote: > >> Trying to make it a flag (which will always be passed a constant value) is a >> clever way to try to get the best of both worlds—and so is the >> chain.from_iterable style. > > At this point it sounds like you're saying that zip(..., strict=True) and > zip.strict(...) are equally bad.
You’re right, it did sound like that, and I don’t mean that. Sorry. zip.strict has _some_ of the same problems as zip(strict=True), but definitely not _all_ of them. And I definitely prefer zip.strict to the flag. At the time I wrote this (I don’t know why it took a few days to get delivered…), zip.strict had come up the first time and been roundly shouted down, and it seemed like.nobody but me (and the proposer, of course) had found it at all acceptable, and I was trying to make the point that if people don’t like zip.strict, the same things and more apply to passing an always-constant flag, so it should be even more acceptable. Then. over the last few days, a bunch of people came around on zip.strict. And that seems to be at least in part because people came up with better arguments than the first time around. (For example, I forget who it was that pointed out that you don’t really have to start thinking of zip as a class and zip.strict as an alternate constructor, because plenty of people don’t realize that’s true for chain.from_iterable and they still have no more problem using it than they do for datetime.now.) So now, rather than it being a +0 for me and a distant second choice behind an itertools function, I think I’m pretty close to evenly torn between the two. I do think that if we add zip.strict, we should also probably add zip.longest, not just think about maybe adding it some day. And it might even be worth adding zip.shortest, even if we have no intention of ever eliminating zip() itself or changing it to mean zip.strict. But I don’t have good arguments for these; I’ll have to think about it a bit more to explain why I think consistency easily trumps the costs for this variant of the proposal but probably fails for other variants.
_______________________________________________ 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/RAFDWYYUIDOLCQ4M7HS35DZL56LR32YX/ Code of Conduct: http://python.org/psf/codeofconduct/
