[cessor]

This circles back to my original argument. Here:

    def adder(x):
        def add(y):
            return x + y
        return add

    add_five = adder(5)
    add_five(10)

How is that different from:

    class adder:
        def __init__(self, x):
            self._x = x
    
        def __call__(self, y):
            return self._x + y
     
    add_five = adder(5)
    add_five(10)

Did you have something like that in mind? Do I understand your idea correctly?

They both allow you to achive the same thing. The syntax doesn't matter, they both produce the same result (in Python, that is, which is a bit unfair, because there, functions are objects to start with -- but even if this was not the case, then the object would require namespacing which is negligible). It depends on whether you want to `think` with a closure or not.

I propose that differences in OOP and FP on this level are irrelevant, but that the magic lies in the naming chosen here. An "adder" is something that has continuity and identity, and the calculation is performed later. I don't care about how it is constructed. There is nothing wrong with just calling add(1, 2) -> 3, but objects give you this deferred stuff for free (sorry, not free, for the price of some memory).

[orisho]

The difference I was aiming at is that you (a library author, whether public or internal) shouldn't implement adder, you should implement add. And let your caller implement adder using add, if they require it. If you only expose adder, you limit possible uses for your library.