On Tue, 12 May 2020 at 07:53, Brandt Bucher <brandtbuc...@gmail.com> wrote:
> > > However, zip_longest is really another beast entirely > > No, it isn't. > > It has a completely independent implementation, a different interface, lives > in a separate namespace, and doesn't even reference zip in its documentation. > So it seems to me that it is indeed another beast entirely. > > > > so it makes sense that it would live in itertools while zip grows > > > in-place. > > No, it doesn't > > See above for why I think it does. ... so it's another beast because (among other reasons) it lives in a separate namespace, and it should live in a separate namespace because it's another beast? That's circular logic. If we were to put zip_strict into itertools, you could use*precisely* this logic to argue that it was the right thing to do. > > > The goal here is not just to provide a way to catch bugs, but to also > > > make it easy (even tempting) for a user to enable the check whenever > > > using zip at a call site with this property. > > Importing necessary functions is not an anti-pattern. > > Um, agreed? So importing zip_strict from itertools is an entirely reasonable way for users to enable the check, then. > > > Another proposed idiom, per-module shadowing of the built-in zip with > > > some subtly different variant from itertools, is an anti-pattern that > > > shouldn't be encouraged. > > Source? > > Point taken. I probably went a bit far labeling this a straight-up > "anti-pattern", but it is certainly annoying to find that someone has added > `from pprint import pprint as print` at the top of a module, for example > (which has actually happened to me before). Very hard to figure out what's > happening. Also irrelevant. It's very easy to suggest bad ways of using a feature. That doesn't make the feature bad. You seem to be arguing that zip_strict is bad because people can misuse it. We could probably remove 99% of the Python language by that argument... Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QYQHK6BWILSORA2XSGV7AUEZJTBUOSIL/ Code of Conduct: http://python.org/psf/codeofconduct/
