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. > But if either of those really did get the best of both worlds and the > problems of neither, it would be used all over the place, rather than as > sparingly as possible. And of course it doesn’t get the best of both > worlds. A flag is hiding code as data, and it looks misleadingly like the > much more common uses of flags where you actually do often set the flag > with a runtime value. It’s harder to type (and autocomplete makes the > difference worse, not better). It’s a tiny bit harder to read, because > you’re adding as much meaningless boilerplate (True) as important > information (strict). But all of this just applies to a flag, not to zip.strict(...). > It’s increasing the amount of stuff to learn in builtins just as much as > another function would. And so on. This applies to both, but it's not true. Both zip.strict() and zip(strict=True) are at least somewhat more hidden and encapsulated than a top level builtin zip_strict(). I also think it's worth questioning something that is being taken for granted. What exactly is the cost of adding a builtin? It's not entirely obvious, at least not to me. Clarifying the precise disadvantages would let us see how well they apply here. You mention increasing the amount of stuff to learn, but I'm guessing 80% of Python coders don't know all the functions in builtins, and that doesn't really hurt them. I wouldn't recommend anyone reading through all of https://docs.python.org/3/library/functions.html <https://docs.python.org/3/library/functions.html#zip> just for the sake of learning it all, do we want to support people doing that? People should just google the builtins they're not familiar with when they come across them. I can see several builtins that I've never or almost never used. When people read the docs for zip, it points them to zip_longest. If zip_strict was in itertools, it would point to that too. Is that significantly better than pointing to zip.strict or even a builtin zip_strict a little further down the same page? I think if someone is reading the docs for zip, it's worth their time to learn all its flavours, and where exactly they read about those doesn't matter. The only time I'm ever annoyed by something being a builtin is that I avoid using it as a variable name. This often happens with id, type, all, list, etc. That wouldn't even be a significant argument against a builtin zip_strict, it doesn't apply at all to zip.strict.
_______________________________________________ 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/5UEUM4FUYL33I7VIFR3J44LUMOO7WAH3/ Code of Conduct: http://python.org/psf/codeofconduct/
