ENH: Adds a const function to functoolz

[llllllllll]

implements #282 based on @d10genes's suggestion

[eriknw]

The "what" of this function is pretty obvious. The "why" may not be, especially for users who don't have experience in other functional languages. I would prefer that the docstring be educational and provide a motivating use case that the typical user may want to use. I can only think of esoteric uses at the moment. If we can't cross this threshold, then I have concerns with adding such a simple function to toolz, because an API is a precious commodity. I'm hopeful that we can improve the docstring.

Also, as currently implemented, the callable returned by const cannot be pickled.

Finally, do you think it would be worth referring to itertools.repeat? I can see const being abused where itertools.repeat would be much more efficient.

[llllllllll]

The most common use that I have is for working with api's that provide a callback argument. Often the callback will be passed a lot of extra information that I want to ignore because I don't need all of these features. What if const was implemented as a class, this would allow us to pickle it and inspect the value for debugging purposes. This also makes it easier for people to use these constant functions without needing to worry about picklability.

[eriknw]

I don't find that use case particularly compelling, because I don't see how it relates to other functionality in toolz. Sure, if I'm building a GUI (for example) that requires many callbacks, then it would be convenient to have a more concise lambda, but where does the rest of toolz fit in? If I have a project that only needs a couple of such callbacks, then I would argue that using lambda introduces less cognitive burden for people who read the code than const would despite being uglier.

Our attention to serializability with pickle and performance with cytoolz is value added, but cannot be the raison d'etre for the inclusion of a function.

So, I still think the value proposition of adding this function needs to be in its documentation, which should demonstrate its usefulness. @d10genes, do you have any suggestions?

[wcbeard]

I'm having a hard time thinking of more general examples, but for me it also seems to come up in the context of larger higher order functions that take a callback. The places where I use it are often similar to places where I may instead use identity.

I looked in the doc string for identity for an example, but didn't see any use cases there, but if someone can think of other contexts where identity would be useful, perhaps it could point to similar situations where const would be useful?

My uses of identity and const (whose results are arguments for higher order functions) are different from my usage of functions like complement (which I find useful in smaller scale, more general contexts), so I am having a hard time coming up with more example usage patterns.

[llllllllll]

I also cannot think of a concrete example; however, I feel like it does fit the use case of identity

[mrocklin]

One might genuinely ask whether identity would be included today if it weren't already in. It's not clear when from toolz import identity is more clear than lambda x: x. That being said, I do end up using identity a lot in test suites. Perhaps I would use const also? Not sure.

I mostly find myself to be skeptical about const. In particular the origins of its inclusion seem odd. It seemed to come from interest like

Hey, maybe we should add X to toolz

rather than

Hey, so I use X all the time. Here are some common cases where I've found it handy, and here's why it's not easy to do with other functions / is somewhat orthogonal/composable.

Now arguably a large fraction of the existing toolz API wouldn't meet this same standard (looking at you interpose). These are mostly still in toolz just for backwards compatibility, though I wouldn't mind going through a deprecation and culling process.

As with all things, I think that the right solution in these sorts of cases is to put it in the sandbox, see if it gets use, and then promote or cull it as that dictates.

[mrocklin]

Another option here is for someone to go start toolshed (or some other, better name). I think that I and Erik have both become a lot more conservative about toolz development recently. As a result a lot of suggested functions get rejected. It would interesting for some more active developer to go out and make a spin off project that was a toolz drop-in replacement that also accepted many many more functions.

Perhaps someone needs to start the Python equivalent of lodash (successor to Underscore in JavaScript).

[datnamer]

Very related : kachayev/fn.py#77

[jacobbridges]

@mrocklin A Python equivalent of lodash already exists, and is pretty darn convenient: https://github.com/dgilland/pydash

[mrocklin]

My intent was to suggest that someone follow the approach that lodash took to javascript. Make
a dropin replacement that also has all the extra stuff, see if people
switch or not.

On Wed, Oct 21, 2015 at 8:17 PM, Jacob Bridges [email protected]
wrote:

@mrocklin https://github.com/mrocklin A Python equivalent of lodash
already exists, and is pretty darn convenient:
https://github.com/dgilland/pydash

—
Reply to this email directly or view it on GitHub
#283 (comment).

[eriknw]

Well said, mrocklin. I would also be critical of identity today even though I too find it mildly convenient in test suites and benchmarks (but that's basically it).

I had an ulterior motive for seeking other toolz functions that const plays nicely with. If the value proposition of const isn't enough to be added to the toolz API (see my first reply), then it may still be possible and educational to define and use const in the docstring of another function. I think docstrings are great places to add little tips.

So, some brainstorming ideas, although I'm not sure any of these should actually be encouraged:

• update_in, although this suggests to me that maybe it could accept either a function or a value:

>>> update_in({1: {2: 3}}, [1, 2], const(5))
{1: {2: 5}}

• valmap(const(val), d) as an alternative to dict.fromkeys(d, val).
• There may be reasonable use cases with juxt.
• As key functions in join. If used as both left and right keys, this becomes a cartesian product. If used as only one key, this becomes a poor-man's filter on the other stream.

Another option here is for someone to go start toolshed (or some other, better name).

I would love to see a toolshed or powertoolz package!