On Mar 27, 2015, at 08:21, Alexander Belopolsky <email@example.com> wrote:On Fri, Mar 27, 2015 at 10:54 AM, anatoly techtonik <firstname.lastname@example.org> 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.
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?