[Python-Dev] RE: Python-Dev Digest, Vol 8, Issue 26

[Jewett, Jim J]

[Brett C.]
> 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
packages.

[Tim Peters]
> 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.

-jJ