Aside: I'm not a fan of the "for humans" label that seems to be common among some Python projects now.
It implies the other tools are possibly designed by monkeys, to a degree, which is often totally not the case.
As a particular example, while some libs are "friendly", they are also limited.
In this case, celery is implied to be not "for humans", but it actually offers distributed job queuing and jobs that can survive a reboot, which is pretty darn important.
I'm not going to name names of other libs doing this, but there are a few that have picked API simplicity over complete feature set. This is obviously a balance - BUT I think it unfairly casts the alternatively libs in a questionable light, and often they can do a lot more.
FWIW, the Ruby-design into the method space can also be reduced if desired to make this a bit more Pythonic (though some things are personal preferences):
Having functions like "Wednesday" or "minutes" complicate programatic usage, where in the above, it would be possible to pass in a constant.
One thing I also notice (not sure if Ruby inspired or not), is that it's keeping global state in the module (see run_pending) rather than having different scheduler objects. This somewhat limits reusability by having this embedded magic and not being able to isolate schedulers.
"For humans" is surely intended to be the opposite of "for computers". It's meant to say "When we designed this thing, we made it a high priority for it to be easy to learn, easy to remember, and easy to use".
There's certainly an implication that other libraries are designed without sufficient attention to human factors, and maybe that's kinda rude, but the same goes for making any positive claim. "A library for efficient high-precision computations": are all the others inefficient? "A flexible and powerful tool for retrieving structured data from web APIs": are all the others inflexible and weak? "A standard-conformant C++ parser": are all the others broken? (None of those examples, so far as I know, are from real projects, but clearly they all could be.)
I also find the "for Humans" thing annoying, but not for the reasons you list. The examples you list are all specific and informative. In the case of "for Humans" what is probably meant is something like "straightforward" or "simple". The thing is, there isn't anything that is NOT designed "for Humans", so the label is meaningless, IMHO.
Monkeys? Where did that come from? The idea of "for humans" just means that the UI was developed with an humane approach - as opposed to an undesigned UI, or one designed merely for the simplicity of the implementation, and that doesn't take into consideration things like our need for consistency to make up for a non-perfect memory.
That said, I personally don't think Celery suffers from this problem, but API that was being replaced by the first project to used this moniker - urllib2 - definitively did.
It's a stand in for something "not for humans". On second thought, monkeys would require an even easier UI. Perhaps "people that like pain".
I don't think it's fair to say the other tools weren't designed, or merely designed the easy way.
urllib2 has some rough edges - and some things should be better, but it can also do some things requests can't do, and I've had to reach for it on a few occasions.
requests has basically optimized for the easy case, where
urllib2 wished to be more flexible in certain areas, so it deserves some merit there too.
The earliest example of this that I could find is from a 2007 article by Jeff Atwood entitled "Sorting for Humans : Natural Sort Order". Coincidentally, Atwood double-dipped on it a few months later with an article called "Monkeypatching for Humans" (but I think he meant "monkey" in a different way).
I think in recent years, Kenneth Reitz has really taken "for humans" and run with it: "Python for Humans", "Deployment for Humans", "requests: HTTP for Humans". He's even gone so far as to (facetiously?) trademark it ("args: Argument Parsing for Humans™"). Now everything with syntactic sugar is "for humans".
If you think your API represents a breakthrough in simplicity then trust me: it will do the talking for you.
It implies the other tools are possibly designed by monkeys, to a degree, which is often totally not the case.
As a particular example, while some libs are "friendly", they are also limited.
In this case, celery is implied to be not "for humans", but it actually offers distributed job queuing and jobs that can survive a reboot, which is pretty darn important.
I'm not going to name names of other libs doing this, but there are a few that have picked API simplicity over complete feature set. This is obviously a balance - BUT I think it unfairly casts the alternatively libs in a questionable light, and often they can do a lot more.
FWIW, the Ruby-design into the method space can also be reduced if desired to make this a bit more Pythonic (though some things are personal preferences):
Having functions like "Wednesday" or "minutes" complicate programatic usage, where in the above, it would be possible to pass in a constant.One thing I also notice (not sure if Ruby inspired or not), is that it's keeping global state in the module (see run_pending) rather than having different scheduler objects. This somewhat limits reusability by having this embedded magic and not being able to isolate schedulers.