But to me it seems to be an idea worth considering to add to python.
I disagree.
It’s true that when people learn about partial(), it is common to wonder about breaking out its left-to-right rule. However, when experimenters go down this path, they create a new problem – how do you specify which argument positions get the frozen values? There are many creative solutions; however, they are all worse than just using a lambda or def to write a wrapper function.
The best attempt I’ve seen is the better_partial project. It has many features, but the core syntax is g = partial(f)(10, _, 20, _, 30) to create the equivalent of g = lambda b, d: f(10, b, 20, d, 30).
Every variant I’ve seen is more complex, less speedy, and harder to debug than a simple def or lambda. Every variant required something extra to learn and remember, unlike def or lambda which are Python basics.
In addition, the use case is questionable. It is mostly an anti-pattern to create functions that take many positional arguments:
>>> twitter_search('#python', 20, False, True, {'US', 'UK', 'FR'}, 'json')
Another problem is that all the proposals I’ve seen restrict you from changing the argument order, from specifying default values, from writing type annotations, and from writing a better docstring. The proposals preclude options that are easily possible with def and lambda, for example:
def python_search(retweets: bool, num_tweets: int, format: str='json'):
'Search #python hash tag in the US, France, and UK for tweets without unicode.'
return twitter_search('#python', num_tweets, False, retweets, {'US', 'UK', 'FR'}, format)
IMO, a more advanced partial() is an attractive nuisance that steers people away from the better and obvious solution that we already have today.