-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
Add a "strict" option for map() #119793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
PEP 618 says:
I'm +1 on the change, personally. Unassigning myself though since I don't have bandwidth to work on it right now (it seems like a good issue for someone newer looking to contribute some C code). |
I want to implement it, but I cant find the definition of |
See Lines 1300 to 1527 in bf098d4
|
The implementation should be almost identical to the implementation for |
Brandt, should I credit you for the code I based my patch on? |
Hey, I'm the guy who originally suggested |
That would be much appreciated, although encukou doesn't think an example is necessary. |
I see the documentation now, I agree an example isn't required. Good job. |
This closes doors to another extension - adding keyword arguments to Maybe it would be worth considering both at the same time and finding out what would be "joint optimum" to have performant & convenient solutions to both?: What about achieving Of course, one can always convert Or is there a reason why adding |
In what case would you not want to supply the same keyword value for all calls though (e.g. using partial)? The benefit for having |
It largely depends on callable in question. If some 3rd party library has provided me with a callable which has keyword which I need to change then I have no other choice. Also, it is not only about having different keyword values, but also overriding the default Also, just realised than @serhiy-storchaka's idea would do the trick for keywords here: #119127 (comment) Although not convinced that this is the best route for that. Alternatively, I think |
The PR is up for a final round of reviews. |
Co-authored-by: Bénédikt Tran <[email protected]> Co-authored-by: Pieter Eendebak <[email protected]> Co-authored-by: Erlend E. Aasland <[email protected]> Co-authored-by: Raymond Hettinger <[email protected]>
Merged! Thank you @nineteendo for your work and patience, and thanks to all the reviewers who chimed in. |
Congratulations @nineteendo , @encukou and all reviewers for delivering this feature! I can't wait to use it. |
The open doc followup issue looks like a no-brainer, but needs review and verification. |
I merged the doc PR. |
…0471) Co-authored-by: Bénédikt Tran <[email protected]> Co-authored-by: Pieter Eendebak <[email protected]> Co-authored-by: Erlend E. Aasland <[email protected]> Co-authored-by: Raymond Hettinger <[email protected]>
…0471) Co-authored-by: Bénédikt Tran <[email protected]> Co-authored-by: Pieter Eendebak <[email protected]> Co-authored-by: Erlend E. Aasland <[email protected]> Co-authored-by: Raymond Hettinger <[email protected]>
These two examples silently truncate the unmatched inputs:
The current workaround is:
Ideally, map() should support this directly. The reasoning is the same reasoning that motivated the
strict
option forzip()
Linked PRs
map()
#120471map(..., strict=True)
over starmap/zip in examples #126407The text was updated successfully, but these errors were encountered: