On Fri, Mar 27, 2015 at 7:55 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

On Fri, Mar 27, 2015 at 12:13 PM, anatoly techtonik <techtonik@gmail.com> wrote:
> Here is something that can be used as an example that it is not about PEP8 https://code.google.com/p/rainforce/wiki/WartsOfPython#measure_time And it takes a lot of energy to collect something like that for the reference.

Well, in that document, I see the total of four "warts" related to the datetime module.  If four warts bring a module to the top of the "worst designed stdlib modules" list, it can only mean that stdlib is almost perfect! 

This is just a personal list of one person for the stuff that is the most annoying to be worthy of spending 4 hours on research and documentation. I've spent at least one working day tracing and recording this down, needless to say that I had to invent the whole concept of wart for the stuff that is neither a bug, nor a feature. The quantity argument that you using doesn't not apply to usability issues. Take any of your gadgets for example. Remember non-USB cables for your phone? How you'd be running around and asking people if anybody has Nokia or Sony or whatever-brand-is-so-smart cable around. This is the wart, and no matter how do you like the phone and your brand and justify Apple use their own cables, for the rest of the world with normal phones this looks weird.
For each "wart" the author has a "What can be done?" section, but no suggested solution involves a major redesign of the datetime module.

Author is me, so you can ask directly. Why I didn't propose to redesign? Because people will assume that somebody will need to write PEP and will force me to write one. I don't believe in "redesign by specification" like current PEP process assumes and people accuse me of being lazy and trolling them, because I don't want to write the PEPs. Damn, I believe in iterative development and evolution, and I failed to persuade coredevs that practices digged up by people under the "agile" label is not some sort of corporate bullshit. So it is not my problem now. I did all I am capable of.

The author complains about non-obviousness of strftime and indeed, for users without C background, neither name nor semantics is familiar.  But the proposed solution

>>> time.format('{{hours}}:{{minutes}}:{{seconds}}', 1090)

Does not look like a big win over the already available solution:

>>> '{t.hour}:{t.minute}:{t.second}'.format(t=datetime.now())

You're evaluating the "big win" using your own biased criteria, not the one that are used by OP. I do not see how this solution makes statement "no obvious way to format time in seconds" false.
Overall, while I agree that there are a few warts in the datetime module, I have not seen any serious enough to warrant a major redesign or even any non backward compatible changes.  Maintaining backward compatibility in the datetime module is indeed non-trivial, but this is the way I think it should be developed.
You're hijacking the issue into BC black hole leaving no chance to provide a better alternative. Let's state that it is obvious that the *behaviour of modules that need a redesign will not change* - the best thing that could happen is that they will get replacements without chronic disease encoded in their DNA. And to engineer that DNA, a proper "scientific method" should be used. "Writing a PEP" is not a method, and "it works for me" is not an argument.
anatoly t.