Moving reduce into functools was more than justified: almost nobody liked it, most people disliked it and if you really want to use if for whatever reason an import is hardly difficult. The decision was made because of the context, not in disregard to it.

The move of reduce to functools makes sense. But it's also inconsistent. map and filter should also be in the functools package tools right alongside partial and reduce. But instead, they're in __builtins__ because .... they're more popular I guess?

I'd actually be OK if map and filter were also in the functools package, but the only way to be consistent while maintaining backwards compatibility is going from the functools package to built-in.

Who disliked it? I used it all the time. Was there any survey or similar?

Guido disliked it. And he's the BDFL.

That's not quite a fair reduction; if it was just down to Guido map would be displaced too, or even gone.

You could quite easily use a process like the one described in the article to select the 'top' 1,000 Python packages, and then scan each of those for occurrences of calls to each of map, filter and reduce, and that way build up a fairly reasonable picture of how commonly each function is used.

While I use reduce a lot, I would guess that even with comprehensions making most uses of map and filter obsolete, that reduce is still the least commonly called of the three.

Better handling of Unicode was also why Python3 adoption has been slow. Upgrading a library or project from Py2 to Py3 is very simple if you already handle bytes vs unicode carefully everywhere in your program.

But for projects that mix unicode and byte strings, and hope for the best (it works okay as long as it is ASCII or UTF8), the upgrade requires substantial work.

Is Unicode handling in Python 3 really better?

http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

Armin is an incredibly smart guy for sure, but I'm not 100% I agree with him on all points.

I don't think he's wrong. I think he's probably right. And, I know it's a rant. I just don't agree that many of his points are "problems."

There are many, many issues that the change fixes. And, like every change, it does break some things. But, it was done for real reasons, not just because: https://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-i...

Some of the reasons were technical, some were very "we should be more standard."

I agree with the Python3 team, here. Mostly because it's more obvious what Python is doing now. But, it's also cleaner in my opinion.

It makes things harder, sure, 100%. But that's not always a problem or a bad thing. In this case, the more work comes with clarity and less chance for bugs (less edge cases).