Thanks Brandt for writting this up. A few notes:
1) already said, but it struck me when I say it: "with nobody challenging the use of the word "strict": A number of us have expressed an preference for "equal" over "strict".
2) "Add Additional Flavors Of zip To itertools" -- I think you're going to need to flesh this idea out, and write a better explanation of its benefits. Maybe one of the folks that are advocating for that could write it. At the very least, specifically mentioning the alternative is to add "zip_equal" or "zip_strict" to itertools, alongside zip_longest(). Personally, I still come down on the add a flag to zip() as the best option, but don't think the alternative is easily dismissed. I would note that while this is written, please be clear that it matters that zip() is a bulletin, and zip_liongest() is in itertools, so there is no way to have the three versions alongside each other for easy discoverability. That is, this would be analogous to having atan() as a builtin, and atan2() in the math module, rather than analogous to having to go to the math module to find all the trig functions, or having related methods on the string object.
3) A number of us prefer to add a string flag or enum: mode= "shortest" | "equal" | "longest" rather than a boolean flag. Yes, this would be redundant with zip_longest(), but it would better address the issue of having two modes in the builtin, and having to go to another module for the third mode. Whether you want to advocate for that or not, it should be mentioned. NOTE: for my part, I much prefer a string flag over an enum
4) " hand-writing a robust solution that gets this right isn't trivial" -- Alex Hall pointed to some great examples of this that you may want to cite.
Thanks!
-CHB
On Sat, May 2, 2020 at 7:02 AM Jonathan Fine jfine2358@gmail.com wrote:
Hi
I've read some posts on this topic, but this is my first contribution.Thank you Brandt for writing the PEP. I like it's clarity. And thank you Ram for making the suggestion that started the discussion. I fully agree, that we have here a problem worth solving. And many thanks for the many other valuable contributions.
Here's a use-case for having a callback. It's the real-world code example given in the draft PEP 618: >>> from ast import Constant, Dict, literal_eval >>> nasty_dict = Dict(keys=[Constant("XXX")], values=[]) >>> literal_eval(nasty_dict) # Like eval('{"XXX": }') {}
If literal_eval resulted in a call to zip(..., strict=True) the outcome would be something like: Traceback (most recent call last): ValueError: zip() argument 2 is too short
It's good, very good, in this situation to get an error message rather than a wrong answer. That would make debugging really hard. And providing a better error message would be even more helpful. How about something like Traceback (most recent call last): AstValueError: Dict called with more keys than values
There. Isn't that even better for the programmer who's got to understand where the error came from. Clearly this outcome could be achieved using a custom callback. Here's the pure-Python implementation in the PEP if items: i = len(items) + 1 raise ValueError(f"zip() argument {i} is too short") sentinel = object() for i, iterator in enumerate(iterators[1:], 2): if next(iterator, sentinel) is not sentinel: raise ValueError(f"zip() argument {i} is too long")
Use this as the template for the custom callback. A simple change to the code allows the result to be an AstValueError, or whatever is considered appropriate.
In the PEP, the only exceptions raised directly by zip are StopIteration and ValueError. I've a question / problem. Wrap zip(..., strict=True) in such a way that the ast example above (taken from the PEP) results in an AstValueError. (Hint: There are traps for the unwary.)
By the way, as the PEP points out, the ValueError can be written as {'AAA':}. So maybe AstSyntaxError would be better.
-- Jonathan _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/2RPQ3Y... Code of Conduct: http://python.org/psf/codeofconduct/