-
-
Notifications
You must be signed in to change notification settings - Fork 29.2k
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
functools.partial placeholders #119127
Comments
Note, this has been discussed and rejected multiple times in the past. Please specifically address these comments:
Also see:
Leaving this open for further comment and reconsideration by other developers. |
[quote="Raymond Hettinger, post:20, topic:19163, username:rhettinger"] In https://discuss.python.org/t/functools-partial-placeholder-arguments/53487 I have laid out several examples and use cases for this. But the main gain here is speed improvement by being able to efficiently utilise functions from [quote="Raymond Hettinger, post:9, topic:19163, username:rhettinger"]
p3 = partial2(opr.sub, _, 1)
print(inspect.signature(p3.func)) # <Signature (a, b, /)>
print(p3.args) # (<partial2.Placeholder object at 0x111e95ad0>, 1) Placeholder sentinel still needs work, it would have much nicer representation. E.g: Personally, I would make use of this functionality in algorithm recipes, iterator recipes, utility functions and similar places of lower level code where performance is important. And I don't see this as Also, Why I think this deserves reconsideration is that this hasn't been implemented and benchmarked before. All the previous attempts were in python, where instead of performance gain which has led me to this point, the result was a significant performance loss - up to 20x slower than current standard library implementation. So naturally, those are not used, because While before supporting reasoning was convenience, Linters, MyPy issues and similar, my main argument is performance. |
I've left this open for comment and no one else has stepped in to opine, so I'm going to go ahead and approve it. The API is a minimal addition that gives more flexibility without venturing into creating a mini-DSL. It is unclear whether it will present any typing challenges beyond what The PR needs a lot of work but the concept is sound. I've been trying it out for a while and it looks reasonable in real code. It supports multiple placeholders but in the examples I've found only one is needed. I'm dubious about the motivation as an optimization (PyPy doesn't need this and CPython may yet optimize a plain |
FWIW, the example I most enjoyed is |
Personally, most of the time I need a placeholder for is when I want right partialization, not left partialization. While there are times where partialization in arbitrary order makes sense, an alternative would to provide |
Feature or enhancement
Proposal:
I know that this has been brought up in the past, but I would appreciate if this was reconsidered. I would be happy to bring this up to a nice level.
The logic is as follows:
vectorcall
change looks like:Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
https://discuss.python.org/t/functools-partial-placeholder-arguments/53487
Linked PRs
The text was updated successfully, but these errors were encountered: