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!)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZX342UGAIZHWKEQGG4OFBYB5DV424KKS/
Code of Conduct: http://python.org/psf/codeofconduct/
