Which is so much easier than dealing with all the crap that Python 3 brought in. Very few people review the APIs in Python 3 now because there are barely any users.
Python 3 is the playground of the cpython developers which seem incredibly disconnected from the real world by now. A lot of the APIs on Python 3 are just bizarre and badly reviewed or completely miss real world solutions for the same problems that people made before. This goes well beyond the bytes and unicode issue even though that will continue to be a huge problem until someone replaces Python 3 as some of the bad decisions in it's design are now so engraved in the API that they will never go away.
Importlib for me is a prime example of a project that lost all direction. It's driven by one or two people and they are developing it without any real world experience with it. I pretty much gave up supporting any of that stuff because with every Python 3 version it changed in new ways and at this point it has lost all portability for me as I need to support from 2.x to 3.4.
Another good example is the general stream interface. While you could argue that the streams are byte/unicode problems they in themselves are an API problem more than a unicode problem. I waste enormous amounts of time trying to make streams work well but the new API is just inherently more complex than before for very little benefit. For the user the new streams are definitely more complicated than the old ones.
While not Python 3 related, but there is a whole new packaging infrastructure project going on in distlib which is used by nobody (with the exception of pip which uses the semantic version parsing of it) besides the original creator and maybe a handful of other people.
asyncio thankfully had Glyph overseeing it, but even with asyncio there are not enough users for the library to go into the interpreter. We're already at the point where there is going to be an updated version uploaded to PyPI which raises the question why it's built-in in 3.4 in the first place, if it's going to change in 3.5 again.
This iterative development worked in Python 2 because of two reasons: a) stdlib packages came from outside the stdlib and were iterated there and b) they were developed out of a specific need and people used it. I don't see this happening for anything in Python 3.
6
u/TankorSmash May 26 '14
The alternative is dealing with those warts that built up. This is a necessary evil!