Should _ fail with ArityError, or return a curried function?

[low-ghost]

Improperly handling arity can be a hard to track down source of error, especially when composing functions, but I would want (_ + _)(2) to return a function that looked like "(x1) => (2 + x1)" such that (_ + _)(2, 3) and (_ + _)(2)(3) would be equivalent and both result in 5.

I can understand the intent of the TypeError and it could actually be the best approach to ease problems dealing with composition and with standard python functions, e.g.

list(filter(_ < _, [9,10,11]))

would be problematic. However, it might be worth considering the curried behavior.

[jacobbridges]

What do you think of adding a "curried" submodule to fn.py? Example:

from fn.curried import _

f = (_ + _)
f2 = f(2)
x = f2(3)
x == 5

And when importing from the normal module, it produces an ArityError:

from fn import _

f = (_ + _)
f2 = f(2)

ArityError: (_ + _) expected 2 arguments, got 1

[low-ghost]

that's definitely a good idea. Doesn't break existing code but gives the curry-all-the-things functional option. I was also thinking _ could be expanded to more operators. In particular I was thinking names = map(_.name, users) would be neat, basically creating a getter for name on whatever dict is sent in. Just now came across a repo that implements it: https://github.com/Suor/whatever. Maybe some interesting ideas on expanding the underscore's capabilities, though it does seem like it leads to a few confusing cases

[jacobbridges]

Making it easier to create lambda functions is (IMO) always a good thing. If we can incorporate the functionality of the whatever object into fn.py's _ object without backward-incompatible changes, then I think we should go for it.

I will set the milestones for these features to be v1.1.0, to give us enough time to plan and build out this feature.

[jacobbridges]

Just redoing the milestones, and I noticed that I cannot set a milestone on this yet. If adding the "whatever" functionality to fn.py's _ will incorporate breaking changes, then this feature should be pushed to v1.0.0. But, if we manage to build out this new functionality without breaking changes, we can push this through in a new minor version (e.g. 0.5.0).

[cad106uk]

Personally I am in favour of having the currying functionality and bumping the the version number.

[Digenis]

There are many possible flavours of underscore, with curry being just one of them.
Let's keep the default one as simple as possible
and provide the alternatives under different names.