Hi Evpok,
Evpok Padding wrote: > Hi, > All apologies if it has been clarified earlier, but if you dislike nested > method calls what is wrong with operating on generators as in No worries! I think the theme of this discussion is using idioms from map, reduce + functions from itertools module themselves. And in my reply to Stephen: > I think this boils down to the itertools module (was thinking about > it over the weekend). > > I find that the itertools module and some builtins like map, filter > don't do themselves justice when chained together. It's okay for > one or two function calls. But the design made it seem like it was > never meant to be chained together (or was it?). Attempts to do > so leads to code that must be read from right to left, making it an > awkward API to use for transforming collections (which most of us > might agree). > > If it was indeed built for one or two function calls, then I would > argue that it's not really a useable or practical module, because > a lot of times we perform not just one or two but multiple > transformations on collections. > > So, to answer this question, I don't think the issue is whether the > implementation is tricky such that the stdlib should do it. Rather, > *our* itertools module itself is tricky to use, because fundamentally > its design is not user-friendly, or rather limiting to the users. And this > is a problem. Head over to StackOverflow and most people wouldn't > recommend using it. It's not well-liked (except maybe by Lisp-ers). > It's most probably because of what I mentioned in the previous > paragraph. > > What does this mean for us? I think it's a good opportunity for us > to rethink the design to make it more usable. Hence, I'm putting > the onus on us (stdlib), instead of relying on 3rd party libraries to > improve on it. > > As a proposal to improve the design, I suggested above a higher- > level API for the itertools module that says "oh you want to use the > itertools module? yeah it's a low-level module that is not meant to > be used directly so here's a higher level API you can use instead." > The implementation doesn't have to be method chaining because > I'm generally proposing a higher-level API. > > Now, I've said that the useability of the itertools module is a problem > pretty much in a matter-of-fact manner and putting it on us to rework > it. But what does everyone else think about this? Do you share the > same concerns too? I mentioned something which I haven't before this: its usability and practicality. I feel like this is the elephant in the room that we could start discussing. And I think we shouldn't avoid it by giving alternatives. Again, these are some sentiments I gather as a Python user and StackOverflow user. _______________________________________________ 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/OZG4UQYU7E7BT3PCVVN6R3SEJ45GYGLN/ Code of Conduct: http://python.org/psf/codeofconduct/
