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.
Everybody does work across an IO boundary. Python 3 had the idea to hide the boundary from you but that trick did not work, now they added escape hatches in through surrogate escapes and other things and made everything worse in the process.
Most people just produce broken code in Python 3 now because if you don't touch it too much, it seems to work.
Just getting command line arguments is boundary code.
It's an OS issue. CLI arguments and file names are always UTF-16 text on Windows and some unregulated binary stuff on UNIX that may or may not be some text in a system-wide locale that may have been changed by another application through setlocale. Naturally, choosing one approach somewhat breaks the other.
0
u/[deleted] May 26 '14
[deleted]