[Python-ideas] Top 10 Python modules that need a redesign Was: Geo coordinates conversion in stdlib

[anatoly techtonik]

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

>
> On Fri, Mar 27, 2015 at 12:13 PM, anatoly techtonik <techtonik at 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)
> '00:18:10'
>
>
> Does not look like a big win over the already available solution:
>
> >>> '{t.hour}:{t.minute}:{t.second}'.format(t=datetime.now())
> '12:37:38'
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150403/eaa6a26a/attachment.html>