feat: support for partialmethod

[MiguelMonteiro]

What does this PR do?

Adds support for functools.partial and functools.partialmethod and closes #664
Still need to write tests and update documentation but would like wait for @mauvilsa to weigh in to see if the idea makes sense.

Before submitting

• [ x] Did you read the contributing guideline?
• Did you update the documentation? (readme and public docstrings)
• Did you write unit tests such that there is 100% coverage on related code? (required for bug fixes and new features)
• Did you verify that new and existing tests pass locally?
• Did you make sure that all changes preserve backward compatibility?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (eee8ea9) to head (66b7ef6).
Report is 3 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #665   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           22        22           
  Lines         6654      6670   +16     
=========================================
+ Hits          6654      6670   +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mauvilsa]

I can't think of a reason why not to support this. Please go ahead and write the unit tests.

[MiguelMonteiro]

I can't think of a reason why not to support this. Please go ahead and write the unit tests.

I was able to add support for partialmethod and added a test for it. For partial functions and classes it's a bit trickier since they are dynamic and it seems the parameter resolver is expecting static objects for the most part.

The options would be to add a subsection in get_component_and_parent that checks if the function_or_class is a partial and handle it separately? Or change the way the attr is obtained form statically attr = inspect.getattr_static(get_generic_origin(function_or_class), method_or_property) to dynamically. But I don't fully understand the downstream effects of these changes.

[mauvilsa]

I was able to add support for partialmethod and added a test for it. For partial functions and classes it's a bit trickier since they are dynamic and it seems the parameter resolver is expecting static objects for the most part.

What was the reason you came to know that partials didn't work? I would guess it was because you needed it for some use case. If it was only for partialmethod, then what is implemented now already works and is a new feature. If you really want partial to also work, later I can take a look.

[MiguelMonteiro]

I was able to add support for partialmethod and added a test for it. For partial functions and classes it's a bit trickier since they are dynamic and it seems the parameter resolver is expecting static objects for the most part.

What was the reason you came to know that partials didn't work? I would guess it was because you needed it for some use case. If it was only for partialmethod, then what is implemented now already works and is a new feature. If you really want partial to also work, later I can take a look.

For classes the main reason is that partial returns an instance of <class 'functools.partial'> which is not a subclass of the original class. This breaks type hints and detecting subclasses as far as I could tell. Additionally, for both Callables and classes, partial returns a descriptor, hiding the wrapped object under __get__,. This requires changes to be made in the parameter resolution at least, but I can't tell if there are other places which would need to be changed to handle descriptors.

For reference, my use case was to create partial classes. I got around the limitations by using partialmethod and explicitly creating a new type (instead of the original type wrapped in partial):

cls = type(
        name,
        (base_class,),
        {
            "__init__": partialmethod(base_class.__init__, **keywords),
            "__doc__": base_class.__doc__,
        },
    )

[mauvilsa]

Looking again at this test now I think there are things missing. The partial doesn't change the list of parameter names. But it does change the defaults. Are the defaults correctly inferred by a parser? If not, then it doesn't really work as expected. So this should be tested.

And another thing that could be considered missing is that a method could be set as default to a callable. For this --print_config should serialize this default into an import path string. And this import path when used in a config, should be correctly deserialize into the partial method object.

[mauvilsa]

For partial functions and classes being dynamic, the import path would also be a problem. If a partial function is saved at the top level of a module in a variable, from the partial function object alone can it be determined what its import path should be?