On Tue, May 5, 2020 at 9:20 AM David Mertz <me...@gnosis.cx> wrote: > I have no idea whether a flag on zip() or a function in itertools would > get MORE USE. I *ABSOLUTELY* think it is an anti-goal to get more use for > its own sake though. >
I'm not sure anyone was suggesting that -- *maybe* Alex, but I think his statement was over-interpreted. I only want APPROPRIATE USE in any case. > I can't imagine we all don't agree with that. > The real point, to me, is that users who use itertools.zip_strict() will > use it for exactly the reason that they want that semantics. In contrast, a > flag for `strict` or `truncate` or `equal` or whatever is a LOT more likely > to be used in the "just in case" code where the programmer has not thought > carefully about the semantics they want. > There's no way to really know, but I think this is being overblown -- folks generally don't go use extra flags just for the heck of it -- particularly one that won't be documented in anything but the latest documents for years :-) > The sky isn't falling, I certainly don't think everyone, nor even most > developers, would use the flag wrong. But a separate function just > provides a better, more consistent, API. > Well, THAT IS the point of discussion, yes. I disagree, but can see both points. But I do want folks to consider that having zip() as a builtin, and zip_strict() and zip_longest() would be in itertools. Which is different than if they were all in the same namespace (like the various string methods, for example). Another key point is that if you want zip_longest() functionality, you simply can not get it with the builtin zip() -- you are forced to look elsewhere. Whereas most code that might want "strict" behavior will still work, albeit less safely, with the builtin. These considerations should be considered in evaluating the API options. And this is why I personalty think if we add a flag to zip, we should add one for longest functionality as well, unifying the API. I don't think anyone in the huge discussion of the walrus operator, for > example, tried to make the case that the goal should be encouraging it to > be used AS MUCH AS POSSIBLE. > Indeed, the opposite was true: there was a lot of concern that it would be overused. though I think think that's a much bigger concern than in this case. A feature should be used *where appropriate*, and the design should not > vacantly simply try to make it more common. > Agreed, but discoverability is still something to be considered in the API. ANd it seems that there are folks arguing that we specifically want this to be less discoveble due to concerns of overuse. Which does not seem like good API design approach to me. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/NTA24XVRJ7CD4B2BAEEIDVPBRFZY6NEQ/ Code of Conduct: http://python.org/psf/codeofconduct/
