[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4