`functools.partialmethod` simplification · Issue #124652 · python/cpython · GitHub

Feature or enhancement

Proposal:

Now, as partial has __get__ and Placeholder it is probably a good idea to simplify partialmethod.

So the mental model of partialmethod can simply be:

partial, which always has the first argument set to Placeholder.

So partialmethod could maybe be a subclass partial, which would potentially simplify things.

Also, maybe there is a way so that partialmethod can be made obsolete altogether.

Will see where I can get to with this.
Any ideas welcome.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

#121027
#119827 (comment)

Linked PRs

gh-124652: partialmethod simplifications #124788

Note that partialmethod also copies __isabstractmethod__ from the underlying callable.

add commented fix if merging after pythongh-124652

PR is ready for review.

Quick summary of what I have done and thought of:

Considered implementing __isabstractmethod__ property for partial so that it returns it from the wrapped function. However, this is not a good idea, because in this case it would be impossible to set __isabstractmethod__ property for it. Also, it would be a divergent behaviour from FunctionType. In short, I kept the same abstract method attribute logic for partial and partialmethod as before.
Relaxed trailing placeholder restriction. This way the behaviour of object is more robust, more functional and behaves naturally given functionality definition. E.g. If I know that Placeholder is for positional arguments, then trailing placeholder will convert it to "positional only". And I can not see a good reason why trailing placeholders need to be prohibited. Also, such behaviour stems naturally from definition of functionality, while forbidding or automatically trimming trailing placeholders would require special mention in documentation.
partialmethod could be made redundant for standard method cases. However, there is one case that it is able to handle that could not be done without it, which is "Unknown descriptor" case, where partial needs to be applied at runtime on callable which is returned from __get__ of wrapped function.

E.g.:

class D:
    def __get__(self, obj, cls):
        return (lambda a, b: None)

class A:
    d = D()

    @staticmethod
    def s(a, b):
        pass

    @classmethod
    def c(self, a, b):
        pass

    ps = staticmethod(partial(s.__wrapped__, 1))
    pc = classmethod(partial(c.__wrapped__, Placeholder, 1))
    pd = ?    # needs `partialmethod`

Thus, I have modified partialmethod so that it does not do any heavy partial-like logic itself, but instead passes all of it to partial.

This allowed removing partialmethod special casing from inspect.signature.

More details in description of PR.

Merge remote-tracking branch 'upstream/main' into pythongh-124652-par…

Likely most convenient merge order

restricting keyword Placeholders: gh-125028: Prohibit placeholders in partial keywords #126062
vectorcall with bound keywords: gh-119109: improve functools.partial vectorcall with keywords #124584
partialmethod simplification: gh-124652: partialmethod simplifications #124788
allowing trailing placeholders: gh-128644: functools.partial: Allowing trailing Placeholders #128649

Merge remote-tracking branch 'upstream/main' into pythongh-124652-par…

`functools.partialmethod` simplification · Issue #124652 · python/cpython · GitHub

Repository navigation

functools.partialmethod simplification #124652

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Likely most convenient merge order

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

`functools.partialmethod` simplification · Issue #124652 · python/cpython · GitHub

Repository navigation

functools.partialmethod simplification #124652

Description

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Activity

rhettinger commented on Sep 27, 2024

dg-pb commented on Oct 2, 2024

dg-pb commented on Jan 6, 2025

Likely most convenient merge order

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions