_ + _ - _

[mentalisttraceur]

Since _ + _ works like lambda a, b: a + b, and _ + _ - 1 works like lambda a, b: a + b - 1, I would expect _ + _ - _ to work like lambda a, b, c: a + b - c.

But unfortunately it doesn't:

>>> ((_ + _) - _)(1, 1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/python3/lib/python3.9/site-packages/placeholder/__init__.py", line 19, in pipe
    value = funcs[0](*args, **kwargs)
TypeError: add expected 2 arguments, got 3

It seems that this is because _ + _ - _ creates F(<function pipe at 0x7fbcee4eee50>, (<built-in function add>, <built-in function sub>)), which if I understand right is more like compose(operator.sub, operator.add), so it behaves like lambda a, b: operator.sub(a + b):

>>> ((_ + _) - _)(1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/user/python3/lib/python3.9/site-packages/placeholder/__init__.py", line 21, in pipe
    value = func(value)
TypeError: sub expected 2 arguments, got 1

[coady]

It works by chaining functions. The first function can handle variadic args; the rest expect a single value return from the previous function call. So even if this was supported, it would look like

f = (_ + _) - _
f(1, 1)(1)

which doesn't seem intuitive.

It should probably just raise an error at construction.

[mentalisttraceur]

Hmm...

So this reminds me of a very similar problem I've been thinking about a lot for function composition (what you're calling "chaining").

So we have compose(f, g)(...) -> f(g(...)).

And there's also partial(f, a)(...) -> f(a, ...).

But really these are both special orthogonal cases of a more general tree-shaped thing... consider:

lambda a, b, c: f(g(a, b), c)
lambda a, b, c: f(a, g(b, c))
lambda a, b, c: f(foo=g(a, b), c)
lambda a, b, c: f(a, bar=g(b, c))

lambda a, *args, **kwargs: f(identity(a), *args, **kwargs)
lambda b, *args, **kwargs: f(*args, b=identity(b) **kwargs)

You see it?

Partial application is binding already computed values to specific arguments, and composition is binding functions to arguments.

So you see how that suggests a callable that does magic(f, g)(*g_args, *f_args, **g_kwargs, **f_kwargs) -> f(g(*g_args, **g_kwargs), *f_args, **f_kwargs) and magic(f, b=g)(*f_args, *g_args, **g_kwargs, **f_kwargs) -> f(*f_args, b=g(*g_args, **g_kwargs), **f_kwargs).

Or in this case: magic(operator.sub, operator.add)(a, b, c) -> operator.sub(operator.add(a, b), c).

In other words, we're looking at the idea of a function tree - a generalization of a function pipe/chain. So perhaps magic should be named "function tree" or partialcompose or something like that.

Of course in the general case, partialcompose requires some non-trivial logic to introspect the signatures of arbitrary callables, "add" them together to know what the final signature of the resulting callable needs to be, and to forward each parameter into the right function in the combined callable. And one of the reasons why I haven't bothered to implement this is because if we already know the "shape" of the call, we can write lambda a, b, c: sub(add(a, b), c) easily, which is clearer than partialcompose(sub, add) and has none of the overhead of introspecting signatures and so on.

But placeholder has a simpler task, because it's just trying to be a better lambda, not partialcompose - just like lambda a, b, c: sub(add(a, b), c) already encodes all information needed to know which arguments to send where, so does (_ + _) - _: once the operator overloads have finished executing, all that information has been seen.

In that second overload, we can detect that one side is the result of _ + _ and the other is _ - doesn't that tells us everything we need to know to switch from a pipe concept to a tree concept?

P.S. I feel like currying as a concept is also potentially useful here, especially the kind of flexibly variadic currying that is possible and common in Python:

from toolz.functoolz import curry
f = curry(lambda a, b, c: (a + b) - c)
f(1)(1)(1) == 1
f(1, 1)(1) == 1
f(1)(1, 1) == 1
f(1, 1, 1) == 1

I don't know if that ends up being relevant or not, but those kinds of curry implementation will inspect function signatures and basically check if they've gotten enough arguments to fire off a call. And one way to implement a positional-only partialcompose (one which doesn't handle kwargs) is like this: partialcompose(add, sub) curries add and sub, then when it gets called with *args, it just takes arguments from the front of args until add returns, then gives the rest of the arguments to sub.

So maybe there's something in all that about either how placeholder could support things like _ + _ - _ or why it might be worth doing.

[coady]

Converted to a discussion since there's no clear path forward.