Raimi bin Karim writes:
📌Proposed implementation Earlier in the thread, Chris proposed a custom class for this kind of pipeline. But what if we exposed this as a Python module in the standard library, parking it under the group of functional programming modules?
The thing is, the reason such a module is needed at all is that Guido decided ages ago that mutating methods should return None, and in particular they don't return self. I'm not sure why he did that, you'd have to ask him, but we respect his intuition enough that to get it in, it would help to have answers to some of the following questions in advance: 1. Is dataflow/fluent programming distinguishable from whatever it was that Guido didn't like about method chaining idioms? If so, how? 2. Is the method chaining syntax preferable to an alternative operator? 3. Is there an obvious choice for the implementation? Specifically, there are at least three possibilities: a. Restrict it to mutable sequences, and do the transformations in place. b. Construct nested iterators and listify the result only if desired. c. Both. 4. Is this really so tricky that the obvious implementation of the iterator approach (Chris's) needs to be in the stdlib with tons of methods on it, or does it make more sense have applications write one with the specific methods needed for the application? Or perhaps instead of creating a generic class prepopulated with methods, maybe this should be a factory function which takes a collection of mapping functions, and adds them to the dataflow object on the fly? 5. map() and zip() take multiple iterables. Should this feature handle those cases? Note that the factory function approach allows the client to make this decision for themselves. 6. What are the names that you propose for the APIs? They need to indicate the implementations since there are various ways to implement.
So this is more of a heartfelt note rather than an objective one — I would love my fellow Python programmers to be exposed to this mental model, and that could only be done by implementing it in the standard library.
I'm with Chris on this. My experience with responding to people on mailing lists is that very few read the documentation until they need to solve a problem that way, and then they read the part that solves their problem, only. Heck, I'm the kind of person who kept a copy of Python Essential Reference at my bedside for a couple years, and *I* don't know half of what's in the stdlib any more. I don't really think putting it in the stdlib will have the promotional effect you hope. As for "only way," I think _Dataflow Programming in Python_ and _Fluent Programming in Python_ are great titles for books. Maybe you could write one of those? I'm half-joking, of course, because writing a book is not something anyone should impose on somebody else. But you do have the passion part down already. :-) (And don't forget to have a cute animal for the cover if you go O'Reilly for the publisher!)