[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Sun, 10 May 2020 16:04:02 - "Brandt Bucher" wrote: > I have pushed a second draft of PEP 618: > > https://www.python.org/dev/peps/pep-0618 > > Please let me know what you think – I'd love to hear any new feedback that > hasn't yet been addressed in the PEP! """ >>> x = iter([iter([1, 2, 3]), iter(["one" "two" "three"])]) >>> xt = list(zip(*x)) """ I'm not sure what the `iter`s bring here. The snippet would be more readable without, IMHO. Regards Antoine. ___ 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/R6F2URBG5ZQCDMVJATCXYLU7U2Y2MWZ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
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/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On 10/05/2020 17:04, Brandt Bucher wrote: I have pushed a second draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any new feedback that hasn't yet been addressed in the PEP! I still don't buy your dismissal of the new function alternative. In particular: It seems that a great deal of the motivation driving this alternative is that zip_longest already exists in itertools. However, zip_longest is really another beast entirely: it takes on the responsibility of filling in missing values, a problem neither of the other variants even have. But zip_equals() is also another beast entirely; it takes on the responsibility of raising an exception, a problem neither of the other variants even have. -- Rhodri James *-* Kynesim Ltd ___ 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/DQDD3WGYNVUKVMANZ6QO6SQBQ7Z44PYJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 618: Add Optional Length-Checking To zip
I have pushed a second draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any new feedback that hasn't yet been addressed in the PEP! Brandt ___ 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/6HTDN4L5PFMOYMUXLTZCGGJYDYMHJGHC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Status of PEP 543 in 2020
Hi, PEP 543, the new TLS api for Python, was published several years ago as a way to a new library unencumbered by the legacy issues around the current ssl library. In the meantime, no actual implementation has appeared. The closest appears to be https://github.com/Synss/python-mbedtls/tree/0.13.0 or https://github.com/python-hyper/pep543 both of which haven't seen much development in years not to mention that neither one has been accepted into the stdlib. The current ssl library could use some improvements to make it easier to use and to expose some more of openssl's functionality (e.g. https://github.com/python/cpython/pull/2449) but it appears that changes have been shelved in favor of PEP 543. Is there any hope for further development on ssl? Is PEP 543 abandoned? Nimish ___ 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/I56OOFAFG26BO25UVWGQS6Q2NZ73MGOF/ Code of Conduct: http://python.org/psf/codeofconduct/
