I seriously doubt 4 will include breaking changes, at least not to the semantics/syntax of the language itself.

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.

>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.

Support for local, per-project installs without hacks like virtualenv.

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'.

* Virtualenv isn't a hack.

* 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.

There are no plans to break backwards-compatibility in Python 4 like Python 3 did with Python 2. If there is any breaking change it will be something like the C API to remove the GIL or something (otherwise it will be standard stuff like removing deprecated modules and functions).

> I seriously doubt 4 will include breaking changes,

If it doesn't, it shouldn't be 4.

You missed the second half of the quote.

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.