On Sun, May 17, 2020 at 2:09 PM Nathan Schneider <[email protected]> wrote:
> If you want a better metaphor: Some door handles include locks, others do >> not. "Strict" ones have locks. So yes, it's possible to leave the lock in >> the unlocked position, and then it functions pretty much the same as one >> without a lock. But likewise, it's possible to leave the door in the >> locked position when you don't have the key on you, and you face a >> significant inconvenience that serves no purpose. >> >> For some of us, strictness is a property that users often want when they > use zip(), whether they are properly enforcing it or not—so giving them a > really easy way to opt into it would help avoid bugs. (Personally, I cannot > remember the last time I actually wanted non-strict zip.) > I think David is saying that he more often wants non-strict zip, and it > would be tempting and dangerous to make strict-zip too easy to use for > those who aren't thinking carefully about their code, so it would be better > to bury strict-zip in itertools for the power users who really know they > need it. (Is that a fair summary?) > The API matter is really orthogonal to this. My point here is that Nathan and some other discussants are operating under the assumption that: "Everyone really wants strict-zip but they just haven't had a way to express it conveniently. They all assume their iterables are the same length already, so this just adds a check." I disagree strongly with that assumption. I think that the actual majority of my uses of zip are non-strict. Admittedly, I have not scanned my code to count that; for that matter, most of the code I have written is no longer accessible to me, being written for companies I no longer work for (and not open source). But whatever the actual percentages might be, I COMMONLY want a non-strict zip by actual specific intention, not because I've made a wrong assumption about the nature of the iteratables I use. Of course, I also commonly use zip with the implicit assumption that my iterables are the same length... I have most certainly written many lines where I would appropriately choose strict-zip if it existed (whichever API). To me, itertools is not some hidden vault only accessible after performing Herculean labors. I believe boolean mode switches are usually a bad design for Python. Not always, there are exceptions like open(). And I think Guido made the good point that one of the things that makes mode switches bad is when they change the return type, which the `strict=True` API would not do (but it would create a new kind of exception to worry about). In fact, itertools is pretty much the only module where I occasionally write `from itertools import *`. There are many good things in that module that are general purpose. But namespaces, after all, are a honkin' good idea. I think if `zip()` were proposed today as a brand new function that hadn't existed, I would advocate strongly for putting it inside itertools. Probably `map()` and `filter()` similarly. So I don't want zip_strict() to join built-ins, but it's not because I think it is a niche case, but rather because I think we already have more in built-ins than we should, and some of it could very reasonably live in a more descriptive namespace. I would certainly not mind if we added `zip_shortest()` as a synonym for the current zip to itertools. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.
_______________________________________________ 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/VP72ECM5JCHVYPRA55M6EL3YLJJQQRJL/ Code of Conduct: http://python.org/psf/codeofconduct/
