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.
What's exactly wrong with importlib and what do you mean support any of that stuff ? It's a py3 carrot - what else do you expect ?
Also, it's kinda weird that you complain about the lack of real world experience. There's a community process and you can get involved in the creation and review of PEPs if you think the PEPs could/should be better.
What's exactly wrong with importlib and what do you mean support any of that stuff ? It's a py3 carrot - what else do you expect ?
How good is a carrot nobody supports? 3.4 changed the importlib interfaces again and deprecated a whole bunch when introducing the module specs of stuff but did not provide replacement functionality.
Also, it's kinda weird that you complain about the lack of real world experience. There's a community process and you can get involved in the creation and review of PEPs if you think the PEPs could/should be better.
I am not using Python 3. All my Python 3 experience is coming from porting libraries for a barely existing user base.
I have zero interest in investing more time into Python 3. I do not believe Python 3 is something that can be repaired in a way to surpass Python 2 in enjoyability for me.
11
u/mitsuhiko Flask Creator May 26 '14
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.