On Sat, Mar 28, 2015 at 3:21 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 27, 2015, at 08:21, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

On Fri, Mar 27, 2015 at 10:54 AM, anatoly techtonik <techtonik@gmail.com> wrote:
Where have you been when PEP 3108 was discussed?  I have not seen any other list of Python modules that needed a redesign, so I cannot tell what's on your top ten list.

Interesting.  I did not see this back in the day.  The top entry (urllib and friends) makes sense and there were heavily redesigned in Python 3.  I am surprised that distutils redesign got less support than logging and datetime. 

I'm not sure how much weight to put on an informal poll of 176 people self-selected as readers of a particular blog in the first place, but...

Back in those days, I think most people had no idea what they wanted from a redesign of distutils, and until at least one of the competing projects to extend/fix/replace it was ready for prime time (at least design-wise) the idea of changing the stdlib to follow one of them was a bit scary.

You're absolutely right that 176 people is hardly a honest poll. It is just an example that this thing is useful, so in ideal world PSF contact somebody who did that and support him with contacts, money, space, and other resources necessary to bring this to the level of representative and authoritative research.
I suspect that this may have to do with logging and datetime APIs not being PEP8 compliant.  Popular votes tend to exaggerate the importance of trivial things such as the spelling of class and method names and brush off more subtle, but important design flaws. 

Interesting point. And I think you're right--but I think you can take it farther.

Even beyond the PEP 8 renaming, what kinds of things did people really want from those modules? People also wanted the 90%-compatible formatting/parsing functions to be 100% Java-compatible for logging and 100% my-plafform's-C-lib-compatible for datetime. And they wanted to be able to plug pytz into datetime without making it so easy to write what looks like correct timezone-aware code but actually isn't. And they wanted easier conversion between datetime's types and those in time and elsewhere.

Those changes aren't as trivial as PEP 8 renaming, but they're still simple to express, concrete, and unambiguous (while still potentially requiring a backward-incompatible change). Who wouldn't vote for that?

I totally agree with all above, except that "Those changes aren't as trivial as PEP 8 renaming, but they're still simple to express" - my opinion is that they are not simple to express. If something is missing, it is absolutely not easy to spot and it requires relatively a lot of time to reach a level of confidence that "no, that's impossible". Thanks to StackOverflow, it is less of a problem today. And still, while it is possible to *express* the changes or the problem somewhere in mailing list, it is absolutely impossible to make an **action item** or at least a **concept to consider for module redesign** out of that. Because you know that happens to those issues and bugs - they are closed, because "it works for me" or "it will break backward compatibility".

anatoly t.