On Tue, 12 May 2020 at 07:53, Brandt Bucher <brandtbucher@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