INADA-san: > We need to avoid major breakage. > But we accept small breakages on every minor release. > And u-prefix is major for now.
IMHO we need a metric to measure the risk of an incompatible change: estimate the percentage of broken Python applications. For example, run the test suite of the PyPI top 100 projects with the incompatible change and see how many fails. That's the root of the PEP 608 -- Coordinated Python release: https://www.python.org/dev/peps/pep-0608/ The "PEP 606 -- Python Compatibility Version" elaborates on incompatible changes: https://www.python.org/dev/peps/pep-0606/ These two PEPs have been rejected since the proposed concrete changes which were not the best options. It seems like the common denominator is the need for a tool to run the testsuite of popular projects on a modified Python and/or the master of Python, to measure how many projects are broken by recent Python changes. It's very different if an incompatible change break 1% or 90% of Python projects. Right now, we take decisions on assumptions without validating them. We push changes and hope that we don't break too many projects. It's rare that we revert incompatible changes that break too many projects, because too few developers test their projects on the beta versions of Python. Most developers and users only test final Python versions. Victor _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XJ7PF3GIA7HCENHB7CM7BSGSAZ3SWAOT/ Code of Conduct: http://python.org/psf/codeofconduct/
