Could sspipe be included as a Core Python module?

https://sspipe.github.io/

https://github.com/sspipe/sspipe

https://pypi.org/project/sspipe/

sspipe allows to use syntax such as:

from sspipe import p, px
import numpy as np
import pandas as pd

(
  np.linspace(0, pi, 100) 
  | p({'x': px, 'y': np.sin(px)}) 
  | p(pd.DataFrame)
  | px[px.x > px.y].head()
  | p(print, "Example 6: pandas and numpy support:\n", px)
)

Before proposing a third party module for inclusion in the standard library, you should check:

- is the module mature and stable?

- does it have an FOSS licence compatible with Python, and if not, are the authors willing to re-licence it?

- are the authors willing to donate the module to Python?

- are the authors happy to change their release schedule to match Python?

- are they happy to adhere to Python's policy on backwards compatibility and new functionality?

- are you (or the authors) willing to write a PEP proposing to add this module to the standard library? https://www.python.org/dev/peps/

- can you find a Core Developer willing to sponsor this PEP? (You can probably ask on the Python-Dev or Python-Ideas mailing lists, or the Python Discuss, or face-to-face in person at a sprint, etc.)

Only after you have done all those things, and got Yes answers to them all, should you propose adding the module. (A single No means there is no chance.)

There was a positive response from package mantainers for this issue :)

See: https://github.com/sspipe/sspipe/issues/4

>> is the module mature and stable?
I am using this module in my own projects for a while and it satisfies my own requirements. However, I think if we want to propose it as a PEP, we should plan for a 1.0.0 release with some improvements on the API and documentation and tests.

>> does it have an FOSS licence compatible with Python, and if not, are the authors willing to re-licence it?
I am willing to re-licence it.

>> are the authors willing to donate the module to Python?
Yes

>> are the authors happy to change their release schedule to match Python?
Yes

>> are they happy to adhere to Python's policy on backwards compatibility and new functionality?
Yes

>> are you (or the authors) willing to write a PEP proposing to add this module to the standard library? https://www.python.org/dev/peps/
Yes, with your contribution.

>> can you find a Core Developer willing to sponsor this PEP? (You can probably ask on the Python-Dev or Python-Ideas mailing lists, or the Python Discuss, or face-to-face in person at a sprint, etc.)
We may try.

I will request support for this project in Python-Dev and Pytgon-Ideas during this week by sending an e-mail.

Thank you also Steven for your bullet points to complete!

Juan

Sorry to burst your bubble, but I don't see a reason to include this in the stdlib. Is there any reason why it can't be a dependency living on PyPI just like the packages you used in the example (numpy, pandas)?

Surely this isn't a category killer? You have *53* stars on GitHub. I think you're misunderstanding the purpose of the stdlib.

Even if it is not currently mainstream, piping (tidy and readable code, left to right), should be a foundation, not just a module.

I'm going to close this. I find your example hard to understand. If you want to discuss this on python-ideas or discourse, go ahead, but this is not ready for a PEP or for stdlib inclusion.

Will discuss it on the Mailing Lists. Thank you.

Yet is important it is important to understand this powerful concept, based on R's pipe:

https://magrittr.tidyverse.org

Eg:

MyObj = Class \
   .method1() %>%
   f_function1() \   # Obj is 1st argument
   .method2() %>%
   f_function2(param1 = "ABC", param2 = .)

And in the last function, the the previous object is saved named as a for "."

And based on previous example, a more "pythonic" syntax would:

MyObj = Class \
   .method1() \
   .f_function1() \
   .method2() \
   .f_function2(param1 = "A", param2 = .)

So that any function preceded by a dot "." becomes a forward-pipe function (Object reference is passed forward).