On 05/10/2020 09:04 AM, Brandt Bucher wrote:
https://www.python.org/dev/peps/pep-0618
Many Python users find that most of their zip usage
I don't think you have enough data to make that claim, unless by "many" you mean five or more.
but silently start producing shortened, mismatched results if items is refactored by the caller to be a consumable iterator
This seems like a weak argument; static type checking could catch it.
the author has counted dozens of other call sites in Python's standard library
References, please.
A good rule of thumb is that "mode-switches" which change return types or significantly alter functionality are indeed an anti-pattern,
Source?
while ones which enable or disable complementary checks or behavior are not.
None of the listed examples change behavior between "working" and "raising exceptions", and none of the listed examples are for "complementary checks".
At most one additional item may be consumed from one of the iterators when compared to normal zip usage.
How, exactly?
However, zip_longest is really another beast entirely
No, it isn't.
so it makes sense that it would live in itertools while zip grows in-place.
No, it doesn't
(importing) 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.
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?
It's not obvious which one will succeed, or how the other will fail. If zip.strict is implemented as a method, zm will succeed, but zd will fail in one of several confusing ways:
How is this any different from calling zip the wrong way?
This proposal is further complicated by the fact that CPython's actual zip type is an undocumented implementation detail.
That actually gives us complete freedom to redesign as long we keep the API backward-compatible. Really, this entire section (alternate constructor type) seems like rubbish. While I agree that mismatched iterators is a problem worth solving, I don't think this PEP comes close to making the case for this particular solution. -1 -- ~Ethan~ _______________________________________________ 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/UC3DYCVISNIFNZWJIPRJA6MLG6V7AALQ/ Code of Conduct: http://python.org/psf/codeofconduct/
