On 1 July 2017 at 21:42, Nick Coghlan <ncogh...@gmail.com> wrote: > 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. >
OK here is the problem with this whole conversation in a nutshell. Each side thinks the other one is bikeshedding and stopped listening to the other. Here is the distributor problem in a nutshell. You will have people come in who are not part of the the upstream community who just want to get some old code they have working. They follow some old written down instructions and find that boom instead of a working thing they now have a broken pile of bolts with no idea why. The usual case in point for the scientific and medical community is some sort of test code run on old data sets which they can not change without rerunning the original experiments over again. They can write new code but that usually requires new research grants etc etc. So some luckless graduate student is given a set of instructions: Fire up a debian/fedora/centos box, install these python libraries and run the code on the data. When it breaks they usually will go spend a long list of finding who to fix it. They go to the upstream and the upstream usually tells them it was a distributor problem because it should have given them foobaz1 libraries vs foobaz4 libraries and they don't deal with foobaz1 anymore. The distribution tells them it is an upstream problem because upstream wants only foobaz to be the name for the latest code. All I am trying to "fix" is that when some luckless postdoc/graduate student/medical technician who really isn't a computer code person but is having to use computer code.. doesn't end up in that situation. The reason I think we should not call the bikeshed blue is because there are still large number of people having to deal with the fact that python isn't the python1 that was originally coded for in the early 2000's for the science experiment. Or heck the fact that the code between python34 and python36 may not work due to some change. Now I can also understand why the upstream wants to paint it yellow by naming one thing python. They have a completely different set of active users who have different problems to solve. They are actively showing up on lists all the time and pushing things. However they are also the sort to tell that outsider "Well you should upgrade your code" (though Python people are much more polite in saying it than other communities). Python also put a lot of effort to try to make changes between 3.4 to 3.5 or 3.4 to 3.6 as easy to fix as possible. The problem is that the person the distributor is eventually trying to solve for isn't looking to port code. They just want it to work. And if they have to port it .. it is going to be something like python1 to python3 or python2.4 to 3.7 vs anything simple. So here we are arguing over blue vs yellow when both have real different problems trying to solve. The python people want to make it easy for their active community to work on whatever distribution they are 'stuck' on, and the distributors are trying to solve for the person who has to come from python1 code and ended up in a python3.7 environment (or even a 3.0 to 3.7 one). > 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 -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
