On Aug 1, 2019, at 22:26, Brendan Barnwell <brenb...@brenbarn.net> wrote: > >> On 2019-08-01 12:31, Andrew Barnert via Python-ideas wrote: >>> On Aug 1, 2019, at 10:48, Eli Berkowitz<eliberkow...@gmail.com> wrote: >>> > >>> >In terms of an argument for why it should be included, for most Python >>> >users the itertools recipes remain unseen. >> Sure. But do you also know all of the functions in the module? Would you >> notice or a new one got added? In practical terms, how much more >> discoverable is groupby than grouper? > > It is massively more discoverable, for one simple reason: autocomplete.
I already mentioned, in that same post you’re replying to, that I sometimes find functions by autocomplete, especially when I can guess at the name. But I rarely use autocomplete to view the entire contents of a module. Maybe using Jupyter in a notebook vs. iPython in a terminal window is different enough that I would autocomplete `itertools.` more often. Or maybe it’s just because I’m old, as others have pointed out about themselves. At any rate, if a lot of other people do autocomplete `itertools.` rather than just using autocomplete to confirm a guess or a vague memory, then it doesn’t matter if I’m not one of those people, so, point taken. > This is a colossal win over having to go the documentation and look > through the text for a recipe that is not "addressable" in any way. You > can't even link to it, for heaven's sake! The function docs in all the > modules have permalinks but the recipes are just unstructured text. That’s a separate issue. There’s nothing inherent in the docs that disallows a link to each recipe, it’s just not the way they’re written. I suspect if someone filed a bug to fix that and submitted a patch, Raymond Hettinger wouldn’t object (or others might override him if he did). > I don't fully understand the resistance to adding these functions to > itertools itself. Honestly, I think a lot of the resistance is the implementation issue, or at least it’s the reason the resistance is hard to overcome. If someone isn’t sure whether the benefit of having itertools.consume is worth the cost of implementing and maintaining it, the fact that the implementation would have to be in C pushes them hard in the no direction. Especially since consume is at least as important as sample code as usable code, so you’d still need to maintain the pure Python “equivalent” in the docs, as with most of the core itertools functions. (And notice that, unlike a Python module with optional C accelerator; a C module with Python equivalent in the docs can’t easily be unit tested to verify that equivalence—and many itertools functions would fail, which is why the docs say “roughly equivalent”.) But if someone did the work to rewrite itertools as a Python-plus-optional-accelerator module (as it would have been if it had been submitted after PEP 399(, or at least as a hybrid Python-re-exporting-from-C, then adding consume or grouper or a set of recipes or even all of them only faces the same hurdle as adding a new function to any already-in-Python module, which is a lower hurdle. But nobody who wants the recipes ever volunteers to tackle that rewrite, prove that it doesn’t break any tests or hurt any benchmarks, etc. And nobody else has any motivation to do the rewrite. > From some other posts in the thread I get the impression some people think > there is (or should be) some sort of multi-tiered system along the lines of: > > 1) in the stdlib > 2) in a "recipe" in the stdlib but you have to copy and paste it > 3) in an "officially sanctioned" third-party lib which is a "category killer" > (like requests) > 4) in a "somewhat less officially sanctioned" third-party lib which isn't a > "category killer" (like toolz?) > 5) in an ordinary third-party lib of which the documentation makes no mention Well, there already _is_ such a hierarchy, but it’s missing the (4) case. That’s why more-itertools is in the less discoverable category 5 today. Whoever proposed that (Chris?) was trying to make things more accessible, not less. > Some of those may be good ideas, but I don't see the use of the > distinction between tiers 1 and 2. It’s partly historical, but not entirely. There’s plenty of recipes in the docs that are aren’t like itertools.consume. Look at the HOWTOs full of recipes for the more complicated modules; they’d become a lot more complicated if you had to make them configurable after import instead of tweakable after copy-paste. And thing about things like the threaded URL downloader—that might be useful, but not in the concurrent.futures library. So eliminating category 2 seems like a bad idea. And it also seems unnecessary for your point. You don’t need to eliminate case 2, or even move the bar between cases 1 and 2, you just need to move the itertools recipes, which are already close to the bar, over it. _______________________________________________ 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/XCCXWTLAVRVLLFPPYMJNZN2HXZGKSC44/ Code of Conduct: http://python.org/psf/codeofconduct/
