On Fri, Jun 30, 2017 at 7:17 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Sat, Jul 01, 2017 at 12:45:51AM +0200, Björn Persson wrote: >> Adam Williamson wrote: >> > 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... >> >> Spot on. >> >> There is a Swedish proverb. I don't know whether an English version >> exists, but in translation it is: One time is no time; two times is a >> habit. Since the Python API has been broken twice, we can expect that >> it will be broken again. > > "Fool me once, shame on you; fool me twice, shame on me"? > But in this case both parties are one and the same, so "Fool myself > once, shame on me; fool myself twice, shame on me again" which does > not come quite as well ;P It's also not an attempt to "fool" people, and it's a quite familiar problem. It's inevitable with any language or program toolkit that uses community published modules, and a core toolkit that is evolving. It's happened with Java, with Ruby, with Perl, and even way back with X11, which used to be X10. (Yeah, I'm that old!) It's not feasonable to declare the core completely static and invulnerable to incompatible upgrades. Heck, I remember when the "mod_perl" module did a major upgrade that was *completely* incompatible with the old versions and insisted, *insisted* on not updating the major release number. In this case, there are many Python modules that are only lightly maintained, and whose current dependencies are not available in older, structurally distinct versions of Python. It's been effective, and reasonable, to maintain a distinction in the package names and to allow SRPM's to compile *both* versions at the same build time, which they do quite effectively. This also helps keep the tool available for alternative default python builds for Fedora, for EPEL, for backporting to RHEL, and even for integration to other repositories like Red Hat's Software Collections Library. That doesn't make it critical to Fedora, but it makes it useful to quite a few Fedora contributors whose email address includes '@redhat.com'. Let's be sensitive to compatibility support for people who are very active in developing Fedora. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
