When I show a novice how to import and use cycle, they they get excited and go off and use it. When I show them how to copy and paste grouper, they sometimes seem reluctant—
TLDR: a beginner can read, understand, and use the itertools module incredibly easily. But putting a recipe aside for your own use later? Forget it. That took my almost 3 years to get comfortable with.
I had this exact reaction for a very long time to doing this kind of thing (copying code and pasting it somewhere).
The main reason is, as a beginner, the entire concept of having a "bag of my own tools" in my own code somewhere (whether copied and pasted or not, doesn't matter) was very intimidating. And it was a near certainly I would forget that I put a thing somewhere to use later, anyway, and I knew it.
And if by some miracle I DID remember, figuring out how to package it up and import it later and fix it if it was broken (assuming that I wrote the code well enough to read and understand it 1 year later!) and then update the stored version and have it perpetuate into other code and tracking what I did and OH MY GOD BEGINNER BRAIN AHSPLODE. I think many people quickly lose track of how hard it is to be new to all of this stuff.
Ricky, thanks for sharing that. I agree that for core devs it is often hard to walk in beginners' shoes (it's one reason I sometimes mentor beginners).
At the same time I think mentors and teachers and book authors should be encouraging their mentees/students/readers to do exactly this: create their own bag of tools to carry around.
I worry that the alternative would be that we'd end up with a stdlib that contains way too many functions to do small tasks that could be expressed in 2-3 lines of code -- this would defeat the purpose of Python as a language that's easy to learn.
Since I'm in a philosophical mood, I'll end with an analogy. When I was a kids, Lego had bricks of various sizes and colors that all fit together. You could build anything you wanted from the limited set of shapes, and they could be recombined endlessly. We were excited when the first bricks appeared with a slanted side so you could make more realistic roofs (only in red!). And wheels were great -- they came in two sizes, small and large (so you could make a tractor).
But when my son went through his Lego phase, every kit came with pieces in all sorts of custom shapes -- airplane wings, ship's hulls, pre-made archways, plus endless accessories for the "guys". And nowadays (a decade later) most Lego kits are strongly branded with things like Harry Potter or Star Wars, and good luck doing something else with the pieces -- it seems you can never find two matching wheels even, or enough red bricks to build a red house.
I don't want Python to become the modern-day Lego. The craft of programming includes being able to combine pieces in all sorts of ways. Now, it's fine for 3rd party packages to have a different philosophy. (Pandas seems to cater to the crowd that wants a function for every conceivable operation, and clearly there's a market for that. :-) But the stdlib ought to remain parsimonious (I think that's the word).