providing aliases corresponding to the functional programming "lingua franca"

[jerabaul29]

Many thanks again for an awesome library.

For what I know, there is not a "hard" standardization on functional programming terminology across languages yet, but still some conventions are found across languages. Some of them are already present in this library (like map, take), some others are not present yet (like filter, reduce, head). The situation is made a bit confusing for people switching between languages, because as said this is not standardized, there are aliases, and conflicting uses of the same terminology here and there.

Still, wondering if this library could be a nice occasion to try to stick to / follow / establish some lingua franca, by using aliases to map to other programming languages.

Some aliases I specially miss and that are more or less lingua franca are, for example, i) filter as an alias for where, ii) reduce (seems not implemented yet?).

• do you think it would be reasonable to go the extra mile in this library, and think carefully / fit to / try to establish some lingua franca?
• in addition (quire related, so putting it here, but could be moved to another issue), regarding the documentation in the readme (section "Existing Pipes in this module"), do you think it may be a good idea / possible to order the entries by alphabetical order, and maybe name all aliases in the line defining the "main" function?

[JulienPalard]

To alias where as filter, feel free to open a PR, I may accept it.

For reduce I don't think pipe can handle it, I deprecated "closing pipes" a year or so ago:

What I mean by a "closing pipe" is a pipe that does not return an iterable, but a value, so itself cannot be on the left hand side of a pipe, "breaking" the pipe, example:

>>> range(100) | filter(lambda x: x % 2 == 0) | sum 

would be readable, OK, but sum does not return an iterable, so no further | can be used. I deprecated this in favor of the even shorter and standard:

>>> sum(range(100) | filter(lambda x: x % 2 == 0)) 

I think reduce enters this category of finalizing pipes so it can't be added, as it would be better written as:

>>> from functools import reduce
>>> reduce(lambda x, y: x + y, range(100) | filter(lambda x: x % 2 == 0))

do you think it would be reasonable to go the extra mile in this library, and think carefully / fit to / try to establish some lingua franca?

No, this library is not aimed to import functional programming to Python, it's aimed to ease infix syntax and that's it. With infix syntax one can do what it pleases, like re-implementing, sed, awk, grep, and whatever, to mimick a shell for example, or try functional programming.

in addition (quire related, so putting it here, but could be moved to another issue), regarding the documentation in the readme (section "Existing Pipes in this module"), do you think it may be a good idea / possible to order the entries by alphabetical order, and maybe name all aliases in the line defining the "main" function?

I would gladly accept a PR with this.

[jerabaul29]

Ok, understand regarding reduce. It is a bit sad, as this breaks some of the "functional programming" syntax look, but fine enough. Just to ask: why was it a problem to have some closing pipes that can only be used at the end of some pipes? As long as it is possible to generate a reasonable error message, that "saves" the user if it is used in the middle of some "normal" pipes, there is no reason for it to be a problem I think?

[jerabaul29]

I sent a couple of pull requests related to what we discussed here, feel free to close. I am still curious about the discussion about reduce, but will move it to another issue.

[JulienPalard]

why was it a problem to have some closing pipes

Multiple little things. First semantically a "closing pipe" is not a pipe. It was making the lib a bit bloaty and harder to understand, as there where two types of pipes behaving differently.

The bloaty part also opened way too much questions like "why not implement XXX as a pipe too", they were often "closing pipes" (like why not | print, | smtp, | json, | log, ...), the answer always being "just give it to the function" (blah | print is the same as print(blah)).

And if someone want one or two "closing pipes" they still can implement it in two lines in their code so, they still can, as the author of the lib I advicse against it but can't forbid it, and I'm OK with this.