Removed keyword Placeholder restriction from this and will issue a separate PR after. Felt like too much is packed into 1 PR.

@dg-pb Is this PR still relevant or have you opened PRs for the different components? If so, can we close this one?

It is still relevant.
On my part this is ready for review.
Given partial.Placeholder has been merged recently and not in production I wasn't sure if splitting is necessary.

I could factor "allowing trailing placeholders" into a separate one if it is preferred.

It is still relevant. On my part this is ready for review. Given partial.Placeholder has been merged recently and not in production I wasn't sure if splitting is necessary.

I could factor "allowing trailing placeholders" into a separate one if it is preferred.

I have not looked at all the changes in detail, but the PR seems big and that could be a reason this PR has not yet been reviewed. In the description at least 3 changes are mentioned (allowing placeholders, performance, refactor for partialmethod). If possible, I would advice to split the PR into multiple PRs.

at least 3 changes are mentioned

There are 2 really.

Performance benefit is a consequence of "allowing trailing placeholders".

I don't mind making changes, splitting as desired etc, but I would like these to be called by reviewer. Otherwise, I already have experience by trying to guess what reviewer might prefer, making changes per suggestions of others, etc and when final reviewer comes he desires to be different again and I need to keep changing things more times than necessary.

And either way these would need to be considered at the same time. I.e. allowing or not allowing trailing placeholders are both ok. There is a slight advantage for allowing them as it makes it a bit more flexible and explicit. While looking at partial from the POV of using it on methods, the advantages and rationale for allowing them can be seen more clearly putting it on a favourable side (at least this is my conclusion).

Also, if I split now, then I have PRs hanging on unmerged code.

the PR seems big

It isn't that big. Most of it is Pure Python rewrite of partialmethod and the implementation is much simpler to follow than the previous one.

As this series of partial related PRs started slowly moving, the path became a bit clearer and splitting this into 2 seems to be the best option to me now. Will do that shortly.

@serhiy-storchaka, just a gentle reminder.
This is ready for final review.

@dg-pb, I am reviewing, I just was very busy last days with other issue.

@serhiy-storchaka, I think it would be good to merge this. Otherwise, it will be sitting there for another version. inspect simplification is what I think has most value here.

This PR is stale because it has been open for 30 days with no activity.

@serhiy-storchaka, I think this can be merged regardless of #128644.

And maybe we could reopen #128644 so that it has another chance for consideration?

Thank you for looking into this.

from functools import partialmethod, Placeholder
class C: # main: TypeError here
m = partialmethod(print, Placeholder) # PR: accepted silently

I added the check so that after this PR this is also raised at definition. I think it is good to keep it in sync with partial and it is an easy one to catch early.

C().m() # main: (, 42) PR: (42,) <- instance gone

Made this PR to behave the same as it was.

Freezing of partialmethod

If you look at pure python partial - these are writable as well, but in C implementation these are read only.

To make partial the same in both versions, all what would be needed is to make read only properties. In this case one can still modify contents of partial.keywords['kw'] = new_val and see the effect.

I made it this way purely for performance - reconstructing on each call is fairly expensive.
I haven't really seen any use cases for mutating args / kwds so I think this change in behaviour is reasonable cost for perf? I see 3 options:

1. Remove caching to keep behaviour in sync
2. Leave it as is and document the behaviour.
3. Make func,args,keywords private with read-only properties. And make keywords return proxy object, which on write actions (setitem/delitem/update/...) clears cache. This would make partialmethod behave the same way as C version of partial. But is it worth the effort?

Would be good to know if being able to modify partial.keywords has found any use cases or is it purely the consequence of not having frozedict at a time?
I would go with (2) and address mutability of both partial and partialmethod separately. I would guess that mutability is not really desirable here and it might be worth considering making partialmethod.args/keywords read only and also make keywords of both partial and partialmethod frozendict.

Perspective of someone with historical context would be very helpful here.

Freezing of partialmethod

If you look at pure python partial - these are writable as well, but in C implementation these are read only.
That would be a good argument for making the attributes of partial read-only (python and C versions should behave the same, I consider the C version leading here).

1. is an option (not sure about the performance impact)
2. is not a good option for me: users setting the argument will not get the original behaviour (e.g. they will get the cached object), but also not an exception
3. Indeed more effort, but acceptable from a backwards compatibility viewpoint: keep attributes as is, but via a proxy or dict watcher clear the cache on mutation (maybe in combination with a deprecation warning)

Lets also see what others think.

So ok, I looked around a bit and it seems that ability to modify keywords of partial has become a feature.

So in terms of restriction and not breaking expected (even though undocumented) contract likely the most sensible thing to do here is to replicate what partial does. If someone has been depending on the fact that func/args/keywords can be replaced by new objects, I think this is something that is ok to put a stop to.

So my solution is as follows:

class partialmethod:
    ...
    
    @property
    def func(self):
        return self._func

    @property
    def args(self):
        return self._args

    @property
    def keywords(self):
        method = self._cachedmethod
        if method is None:
            return self._keywords
        if isinstance(method, (staticmethod, classmethod)):
            method = method.__wrapped__
        return method.keywords

So in case the method is cached, give keywords of underlying partial object. An in case descriptor is not yet built or is in state of being built on every call, then return partialmethod._keywords.

Subclass optimization also works correctly via:

temp = partial(lambda *_, **__: None, *func._args, **func.keywords)

Freezing of partialmethod

Made changes. Now:

1. Backwards compatibility is preserved. Provided script now gives same answers when run with main and this branch (except __slots__).
2. Performance benefit is retained (updated timings in description).

There are some more behavior changes

from functools import partialmethod

class Desc:
    """Standard descriptor idiom: return self on class access."""
    def __get__(self, obj, cls=None):
        if obj is None:
            return self
        return lambda a, b: ("bound", a, b)
    def __call__(self, *args):
        return ("Desc.__call__", args)

class A:
    pd = partialmethod(Desc(), 1)

a = A()
print("before class access:", a.pd(2))
A.pd                       # any class-level access, e.g. inspect.getmembers(A)
print("after class access: ", a.pd(2))

and

import inspect
from functools import partialmethod

async def coro(self, a): ...

class B:
    pm = partialmethod(coro, 1)
    ps = partialmethod(staticmethod(coro), 1)
    pc = partialmethod(classmethod(coro), 1)

for name in ("pm", "ps", "pc"):
    print(name, inspect.iscoroutinefunction(getattr(B, name)),
                inspect.iscoroutinefunction(getattr(B(), name)))

So my solution is as follows:

We could also build the descriptor if keywords is accessed. A bit slower for some cases, but maybe safer.

There are some more behavior changes

Ok, I have contained caching only to intended set of types. I think this solves all discrepancies. But would appreciate another look.

We could also build the descriptor if keywords is accessed. A bit slower for some cases, but maybe safer.

Specialised descriptor would return something different than dict and this would break existing type(pm.keywords) is dict.

I think I have preserved full backwards compatibility now - even ability to set func/args/keywods. Although I think it would be ideal to keep it consistent with partial, I think it is best to limit scope of this to what was initially intended.

@dg-pb There are some more issues with the current iteration. I will add (AI generated) reproducers in the details section below. Getting this right turns out to be trickly. I suggest to split this PR into multiple smaller ones: i) add the regression tests found so far (at least the cases where we do not want to change behaviour) ii) Placeholder binding plus inspect cleanup (should make the code cleaner) iii) some form of caching for performance.

def f(self, a, b=0): return ("f", a, b)
def g(self, a, b=0): return ("g", a, b)

class A:
m = partialmethod(staticmethod(f), 1)
A.m # populate the cache
A.dict['m'].func = g # switch staticmethod -> plain function
print("staticmethod -> function:", A().m(2))

class B:
m = partialmethod(f, 1)
B.m
B.dict['m'].func = staticmethod(g) # plain function -> staticmethod
print("function -> staticmethod:", B().m(2))

import pickle
from functools import partialmethod

class A:
def m(self, x, y): return (x, y)
pm = partialmethod(m, 1)

bound = A().pm
print(pickle.loads(pickle.dumps(bound))(9)) # multiprocessing.Pool.map(a.pm, ...) needs this

import inspect
from functools import partialmethod, partial

class Desc:
"""Not callable itself; returns self on class access, a callable on instance access."""
def get(self, obj, cls=None):
if obj is None:
return self
return partial(lambda o, a, b: (a, b), obj)

class A:
pd = partialmethod(Desc(), 1)

print("instance:", A().pd(2))
print("class: ", A.pd) # main: function, PR: TypeError
print("members: ", [n for n, _ in inspect.getmembers(A) if n == "pd"])

</details>

@eendebakpt thank you for pushing on this. Indeed it did get tricky from another angle as well -- in the end I couldn't find a way to deal with keywords without forbidding setting new func/args/keywords attributes.

I think by this time the promise of "simplification" in the title is failing badly and I agree - let's leave caching out.

And it might be a better call in general - after all, now, at least for simple cases, partial+Placeholder should be preferred - explicit, cached by default and much faster. So I think tidying things up while not breaking stuff is the right scope.

So:

1. Caching removed
2. Added regression tests (but left couple out that are targeted at caching specifically - after this attempt, I don't think there is much chance that it is worth the effort)
3. All reproducers passed without any issues except the last one where partial refused to construct with non-callable object. For that one I added a special case.
4. Removed NEWS as there isn't anything to brag about anymore.

Take a look, I think this is getting close to something that actually works.