[Python-Dev] RE: Python-Dev Digest, Vol 8, Issue 26
Jewett, Jim J
jim.jewett at eds.com
Thu Mar 11 18:13:11 EST 2004
> I would love to hear Gustavo give a quick comparison ...
> of what DateUtil provides over datetime.
This is important, because the standard library is already
starting to suffer from bloat. (Too many module names,
not too much utility.)
Namespaces help; the Mac-specific modules might be
overwhelming if so many weren't nicely wrapped in Carbon.
I have no idea whether the Carbon.* modules are at all
related on a technical level, but I don't care -- grouping
them makes it easier to ignore the whole batch at once,
instead of running into them one at a time. (Hmm, would
a preferences module be useful? Oh, wait, its Mac-specific.)
If I want to deal with time in some way, I already have to
decide between (at least) calendar, datetime, and time, and
perhaps locale (for printing). I'm not saying that they all
do the same thing; I'm saying that the name alone doesn't
tell me which to use, so I have to either guess, or read the
documentation for each.
If useful parts of DateUtil migrate into a standard module,
that's great. Maybe even as what appears to be a submodule,
like datetime.DateUtils. But adding yet another alternative
just makes things more confusing; people ready to sort them
out on their own are probably willing to install third party
> datetime stuck to things people can't reasonably argue
> about, while DateUtil (like mxDateTime before it) is in
> the business of guessing what people really want. ...
This is a useful distinction.
Unfortunately, it isn't clear from the name. I suppose the
module documentation (for both modules) could say this right
at the top. It also works well with placing DateUtils inside
one of the current modules; it will seem like a specialization.
More information about the Python-Dev