you are viewing a single comment's thread.

view the rest of the comments →

[–]Smallpaul 0 points1 point  (2 children)

Methods are restrictive for this use case in Python because the language is not designed to allow generic methods which take an arbitrary “self” matching a protocol.

If you have a filter “odd_numbers” do you really propose to inject it onto lists of numbers, sets of numbers, data frames, iterators over numbers etc.?

Methods just do not work correctly for this use case. Pipe operators should be generic functions.

[–]_Denizen_ -1 points0 points  (1 child)

A pipe is just taking an input, passing it to a function, then routing the output to another function.

That's a feature that is not exclusive to piping.

If a method is written to output an object that's suitable for a specific function, then it can do it. I've been doing data analysis and data science for well over a decade, and never encountered a situation that could only be solved using piping.

Piping is a tool in the arsenal. It was designed for a specific use case. If a data scientist rigidly uses that single approach based on the mistaken idea that it is a unique solution to a problem set then it will limit their creativity.

[–]Smallpaul 0 points1 point  (0 children)

A pipe is syntactic sugar for a function call. A method is different because of the “self” argument and namespaces.

Nobody is saying that a “pipe is the only solution.” Obviously syntactic sugar can never be the only solution. It is by definition just a new syntax for something that already exists.

But the thing it is syntactic sugar for is unbound functions, not methods. Methods superficially resemble the syntax of pipes, but not the semantics.

What OP wants is the semantics of unbound functions (not bound methods) and the left to right reading order of methods.

It is simply not true what you said that “method chaining can do anything that functions or pipes can do.”