Project:Python/Adding and Removing Python implementations

When can I remove Python implementations from PYTHON_COMPAT?
It ever so happens in the Python implementations lifecycle that new implementations come, and old ones go. You may ask the question, "when can I safely remove old implementations from ?" The answer in general: only after the implementation has been removed from the tree. The corollary of this is that, once you have committed an ebuild to the tree using a certain set of Python implementations, you have to stick with this set at a minimum (until implementations have been removed from the tree).

Example
Let's say you have  with. Now  has become somewhat stale but is still a stable Python version in the tree. You decide that you don't want Python 3.3 support anymore for your package, revbump your ebuild to  and now set. This is dangerous and should be avoided, as it can lead to a broken depgraph, due to a now more restricted set of  dependencies. An example of such breakage: https://github.com/gentoo/gentoo/pull/2134#issuecomment-242564642

But upstream officially does not want to support Python implementation X.Y!
In general correctness is more important for Gentoo than what upstream desires. While we recognize that running unsupported configurations might cause issues for us too, the deciding issue here is whether all testsuites pass: If a package passes its complete testsuite without errors (or the same errors as more modern implementations), then for Gentoo Python implementation X.Y is considered working and we keep the implementation in.

When can I add Python implementations to PYTHON_COMPAT?
Adding Python implementations that you believe are safe and pass all test suites can be added to an ebuild, without revbumping it. The changed  flags will trigger a rebuild for users with the newly added python implementation enabled, and will be ignored otherwise. This keep rebuilds of packages to an absolute minimum, yet allows testing for newer implementations. As the number of possible  dependencies increases, the depgraph will not result in unsatisfied dependencies, making it safe to add new implementations (all other dependencies permitting of course).