On 1 July 2017 at 03:36, Adam Williamson <adamw...@fedoraproject.org> wrote: > On Fri, 2017-06-30 at 12:07 +1000, Nick Coghlan wrote: >> Even if a 4.0 does happen, the magnitude of the change relative to the >> preceding 3.x release is expected to be comparable to that between any >> given 3.x and 3.x+1 release, so it wouldn't require the parallel stack >> approach that has proven necessary to handle the core data model >> changes that impacted the 2->3 transition. > > I thought it would be tolerably obvious that I didn't mean "literally > the specific conceptual Python 4.0 that at one point was expected to > exist after 3.9" or "any specific Python 4 release that happens". > Clearly what I meant was "any future non-backwards-compatible major > Python release". Maybe *right now* you don't expect there to be one, > but I'm sure there was probably a point during Python 1's lifetime at > which no-one expected there to be a backwards-incompatible Python 2, > and a point during Python 2's lifetime at which no-one expected there > to be a backwards-incompatible Python 3...
No, as in the process of maintaining Python 2 & 3 in parallel for over a decade, we've significantly improved our toolset for *not* painting ourselves into similar corners in the future (and we're likely to introduce even more technical capabilities along those lines over time, such as Victor Stinner's proposal for a more flexible runtime code transformation pipeline). Now, obviously, we can't *stop* redistributor communities like Fedora from collectively declaring those process, policy, and technology changes ineffective, and instead investing their time and energy in planning for future disruptions that probably aren't going to happen. However, we *can* provide the advice that we don't believe such endeavours are going to represent a good use of that time and energy. In this case, that means pointing out that the Python maintenance team's proposed migrations strategy (including eventually updating unqualified Python references to mean Python 3.x) is fully aligned with upstream's planned maintenance policies, and that I personally believe that any lingering concerns about potential forward compatibility problems would be better addressed by progressively introducing tools like static structural analysis with "pylint -E" and gradual type inference with mypy into Fedora's automated testing infrastructure. Cheers, Nick. P.S. The variants of the saying I'm familiar with: - once is an accident, twice is unfortunate, three times is a habit - once is an accident, twice is coincidence, three times is enemy action At the moment (over the course of ~26 years), we're at once for semantic breaks in the core runtime data model (e.g. concrete lists->assorted iterable types in 3.0, 8-bit str->Unicode str in 3.0), and twice for introducing breaking changes without a prior deprecation warning (assorted changes in 3.0 that aren't yet covered by the -3 switch or `pylint --py3k`, function arg handing changes in 2.0 [1]), so we're putting significant effort into making sure neither of those becomes a habit :) [1] https://docs.python.org/3/whatsnew/2.0.html#porting-to-2-0 -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
