I think this is a nice healthy view to have about Python 2 to 3. Can't wait until python 4!
What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.
Such as?
I really hope I'm not going to start needing 1,200 dependencies to build a simple app like I would in node.
Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer.
Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary.
Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain.
Support for Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard
Standard support for direct install from GitHub without weird hacks.
Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck.
Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package.
Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to publish a package and the package manager 'just works'.
* Setup.py/MANIFEST.in seems like a pretty clear answer to me.
* I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment.
* Yes, I do it pretty frequently.
* "MD os the defacto standard" Huh? According to whom? ReST is fine.
* "Standard support for direct install from GitHub without weird hacks." - stick "git+https://github.com/yourname/yourpackage" in your requirements.txt and off you go.
* Yeah, they should really standardize on pip, but this is relatively minor.
* Use one of the templates.
* Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.
If it doesn't, it shouldn't be 4.
Breaking changes to the language syntax/semantics.
I'd expect breaking changes to apply to core APIs and/or to external tooling as both could probably use some revision now that the fundamental issues with the language (ex utf8 support) are mostly fixed.