This library is not going to divert much (any?) effort that could have improved other date-time libraries.
This library is not going to divert much (any?) effort that could have improved other date-time libraries.
Other stuff that are splitted:
- attention;
- visibility;
- pull requests;
- documentation edits;
- bug reports;
- installs (and hence testing on the field);
- compatibility layers;
- compatible tooling;
- 3rd party tutorials, snippets and examples;
- help from integrators;
Now if you don't have any very good alternatives, it's good : you want to steal that from them. But when you DO have good existing projects, then those are the bread and butter of their success.
Now I know it's way harder to contribute to something than roll you own. I know that's it's also more fun to roll your own. And there is the ego at play as well.
I understand all that, and I respect Kenneth as a professional. But I don't think it's a good call on his part here.
It is espacially true for him, because he now have such a good rep in the Python community that everything he does get under the spotlight.
Even taking all of what you mentioned into account, it's still not more than a single afternoon.
I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that.
[1]: https://github.com/kennethreitz/maya/blob/master/maya.py
Trying to funnel someone with an itch into a project is a bit like making someone on meth fill out paperwork: kills the buzz and works out poorly. And if just one human understands the nightmare of date handling a bit better, it is a positive thing for the humans.