[Python-Dev] RE: Python-Dev Digest, Vol 8, Issue 26 (original) (raw)

Jewett, Jim J jim.jewett at eds.com
Thu Mar 11 18:13:11 EST 2004

[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

More information about the Python-Dev mailing list