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 <jfine2...@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-le...@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/2RPQ3YDKGTV3TVFA76MRYNXSLVLVDSJE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/O6P73DSHZ5NEDGDRBIM24N64SEWBRY3T/
Code of Conduct: http://python.org/psf/codeofconduct/
