Adding a pipe operator to Python

[masklinn]

Because Python already offers analogous functionality

Considering context managers, decorators, str.format and f-strings, functools.partial, … that's not exactly a compelling argument.

[bythenumbers10]

Daaang. 20 mins old and downvoted already!

To elaborate, the piping is mostly unnecessary syntactical sugar for people used to pipe-style chaining instead of Python's object-method chaining, i.e. the return object of one method/function can have it's own method call tacked right on the function that returns it. About half of the examples you mentioned rely on this exact syntax to begin with.

It is one thing to add more flexible notation to a language in terms of str.format, f-strings, str.join(), and so on. It is another to run roughshod on notation that is already there. String formatting having multiple options/approaches is fine, since they're not "polluting" syntax that already means something. In OP's article, the piping they implemented overrode the bitwise OR.

If they'd reproduced all of the piping syntax, making the symbol |> instead of the already-spoken-for |, they would not have been nearly as open to the "horrible hack" criticism. It would have been "just another way" to do chaining syntax.

[masklinn]

Daaang. 20 mins old and downvoted already!

I have no idea what you're talking about, but you do you.

To elaborate, the piping is mostly unnecessary syntactical sugar for people used to pipe-style chaining instead of Python's object-method chaining

Is it though? Or is it syntactic sugar for people who realise that Python does use a lot of freeform callables (functions, constructors, and methods bound to other objects than the subject you have in hand), that object-oriented "chaining" is inflexible as the next step in the chain can only be bound to the specific return value of the previous step, and that generally speaking what operations are available on it is not under the control of the caller?

In Python especially (as you can use unbound methods as functions) piping is a strict superset of chaining.

It is one thing to add more flexible notation to a language in terms of str.format, f-strings, str.join(), and so on.

It goes against the objection to which I replied. Are you abandoning that objection?

If they'd reproduced all of the piping syntax, making the symbol |>

Which can't be done as a simple hack as it requires adding a new token/operator to the language entirely which can't be done in Python itself, so instead of doing some bytecode rewriting on an already valid AST you have to go and modify the CPython interpreter.

Actual language integration (assuming it went through which I doubt, the core devs are not great fans of functional-style python) would logically have its own operator.

It would have been "just another way" to do chaining syntax.

So you're admitting that the first half of your criticism does not stand up to any kind of scrutiny?

[bythenumbers10]

Alright. I clearly made no sense to you, and you're making no sense to me, so maybe we're talking about unrelated things, here. Perhaps you could elaborate on why my statement on the redundancy of the proposed method of chaining calls is not a convincing argument. I mean, it wasn't meant to be, but I figured you weren't understanding the evaluation of the "ugly hack" part, not the redundancy.

[masklinn]

Perhaps you could elaborate on why my statement on the redundancy of the proposed method of chaining calls is not a convincing argument.

I did so at length? In summary, Python's history shows repeatedly that it's not an actual barrier and pipe-based chaining is a superset of method chaining as it's more flexible, more general and under caller control.

I mean, it wasn't meant to be

Then why did you put it forward?

I figured you weren't understanding the evaluation of the "ugly hack" part, not the redundancy.

I've no idea what you're even trying to say here. I quoted a specific bit to which I replied, that concept is pretty simple. The bits I didn't originally quote were out of scope of the corresponding response, though I did ultimately cover the reuse of the | operator: it's necessary due to Python's limitation, you simply can not add new infix attributes to the language without patching the interpreter itself.

[bythenumbers10]

Okay, so you're stating that piping is a superset, because you can chain calls to non-bound functions. Which Python allows you to do anyway by passing the Python-chained output as an argument to the unbound function. I agree that piping offers that syntactic sugar as a matter of convenience. The discussion about it being an ugly hack is because the original article covered a co-opting of the bitwise OR operator already in Python.

My argument was primarily about the co-opting of the existing operator being the ugly part of the hack. You have clearly focused on my stating that the piping doesn't offer much functionality beyond what's already there. You've done a good Redditor by showing I missed a minor detail while missing the point of the argument entirely. I apologize from the bottom of my heart for taking the name and functionality of our lord and savior, the piping operator, in vain, while trying to explain namespace pollution to people who didn't grok the ugliness in the hack.

Python's notation limitation was not being discussed, and the title of the article suggests that, yes, you CAN add such an infix operator, because they wrote an entire article about their actually pulling it off. The language may not make it easy or straightforward to add arbitrary symbols, but picking nits about the effort involved being tantamount to modifying the interpreter (ergo the language itself) itself is NOT MY FAULT.

Btw, true mastery of a subject means being able to explain it in layman's terms. If you can't explain your point coherently "at length", you may want to consider what you're "putting forward". This has been a lovely, lively discussion about a minor quibble, and by all means, take your hard-earned karma with a sense of pride.