core: improved method tools

[ethanglide]

Add functionality for transforming methods and classmethods into tools. This is an improvement over the implementation in #28160.

Resolves #27471

Example:

class A:
    def __init__(self, c: int):
        self.c = c

    @MethodTool
    def foo(self, a: int, b: int) -> int:
        """Add two numbers to c."""
        return a + b + self.c

a = A(10)
a.foo.invoke({"a": 1, "b": 2}) # 13

Example with classmethod:

class A:
    c = 10
  
    @MethodTool
    @classmethod
    def foo(cls, a: int, b: int) -> int:
        """Add two numbers to c."""
        return a + b + cls.c

A.foo.invoke({"a": 1, "b": 2}) # 13

This implementation requires the programmer to specify @MethodTool rather than using the @tool decorator, which allows for a much better implementation which gets over a lot of shortcomings of my previous attempt in #28160. Some improvements are as follows:

• The first parameter of the method is not required to be named self or cls, it can be any name
• The argument name outer_instance is no longer a "claimed" parameter name. Parameters can be of any name
• classmethods are fully supported

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langchain	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 14, 2024 2:02am

[efriis]

thanks! a few suggestions and questions

[efriis]

can we make this a function instead of a class?

[efriis]

I see - this maybe solves the issue of typing. going to suggest some ideas - not sure if they work

[ethanglide]

The class is needed for classmethod support. I have created a wrapper function methodtool that simply returns MethodTool(func). How's that?

[efriis]

why is it needed for classmethod support?

[ethanglide]

I mentioned in another reply:

With the way the __get__ descriptor works owner is for the class itself and instance is for the instance of the class.

Keep in mind that in your other solution (a function that returns a property), you are still returning a descriptor class. That class, property. works for our regular method tool case, but it will not work for class methods. Notice in the MethodTool class that it will pass in owner (class itself) for outer_instance with classmethods, and instance (class instance) for regular methods. Since the property class is not enough for our use, I had to create a custom descriptor that did exactly what we wanted it to.

"Why could we not do classmethod(property(func)) for classmethods?" you may ask. That is because classmethod no longer wraps descriptors as of Python 3.13.

If, for syntax reasons, you would like the decorator to be a function that is something that I have added to the code. The function is simply a wrapper for the MethodTool class since that overloaded __get__ method is needed, but the MethodTool class never needs to be exposed to client code.

[efriis]

Suggested change

	class MethodTool:
	"""A descriptor that converts a method into a tool."""
	def __init__(self, func: Union[Callable, classmethod]) -> None:
	self.func = func
	def __get__(self, instance: Any, owner: Any) -> BaseTool:
	if isinstance(self.func, classmethod):
	return tool(self.func.__func__, outer_instance=owner)
	return tool(self.func, outer_instance=instance)
	def toolmethod(f: callable) -> property:
	"""A decorator that converts a method into a tool."""
	def inner_f(outer_instance) -> BaseTool:
	tool_f = functools.partial(f, outer_instance) # this substitutes in for self
	return tool(tool_f)
	return property(inner_f)

[efriis]

this leaves out what was being handled by owner vs instance for outer_instance - what is that doing for us?

[ethanglide]

That was to allow the support for classmethods. With the way the __get__ descriptor works owner is for the class itself and instance is for the instance of the class.

[efriis]

Suggested change

	assert "cls" not in A.foo.args
	assert "cls" not in A.foo.args
	class A:
	...
	class TestStandardAUnit(BaseToolUnitTests):
	...
	class TestStandardAIntegration(BaseToolIntegrationTests):
	...

would also be good to implement some of these as standard tests - it tests a few of the exhaustive cases: https://python.langchain.com/docs/contributing/how_to/integrations/standard_tests/

sorry this is dragging on a bit! appreciate your help!

[ethanglide]

This seems cool, I've never heard of this before and would like to give it a try since it could make the tests more concise. But I am having trouble putting them into the test_tools.py file. The issue comes from being unable to import the ToolsUnitTests class.

[efriis]

also before starting too much work @baskaryan had a suggestion for how to document this behavior without needing code changes. He smartly suggested that the underlying issue with decorating methods with anything is that it incorrectly decorates Class.method instead of the object's self.method instance, so it may be better to just document that instead, with a way of adding a separate property/method that generates that for you if you so wish

[ethanglide]

also before starting too much work @baskaryan had a suggestion for how to document this behavior without needing code changes. He smartly suggested that the underlying issue with decorating methods with anything is that it incorrectly decorates Class.method instead of the object's self.method instance, so it may be better to just document that instead, with a way of adding a separate property/method that generates that for you if you so wish

Sorry, I don't think I understand. I get that the decorator does decorate Class.method instead of self.method, but with the way things are currently set up even if you decorated the method within the constructor (which would decorate self.method) you would still be unable to use the tool because of the conflicting names of the self parameter. There would need to still be code changes.

However, since we know we can create this decorator which does the job we want and works with a very similar interface to the current @tool decorator, why not do it?

[baskaryan]

hey @ethanglide, appreciate the pr! i have a strong bias against adding more interfaces that sound/seem very similar and have similar functionality. thoughts on documenting this type of usage of the existing @tool instead of introducing another decorator?

from langchain_core.tools import tool, BaseTool

class A:
    def __init__(self, c: int):
        self.c = c

    def _foo(self, a: int, b: int) -> int:
        """Add two numbers to c."""
        return a + b + self.c
  
    @property
    def foo(self) -> BaseTool:
        return tool(self._foo)

a = A(10)
a.foo.invoke({"a": 1, "b": 2}) # 13