On 01.08.2017 01:40, Nick Coghlan wrote: > On 1 August 2017 at 03:47, Barry Warsaw <ba...@python.org> wrote: >> On Jul 26, 2017, at 00:29, Nick Coghlan <ncogh...@gmail.com> wrote: >>> >>> At the PEP 394 level, what I'd personally like to see us do is to >>> split the "Recommendations" section into two separate sections: >>> "Python User Recommendations" and "Platform Publisher Recommendations” >> >> I’d like to keep PEP 394 as short and proscriptive as possible. I’ve always >> read PEP 394 as being aimed at “platform publisher recommendations”, i.e. >> distributions who provide. I think a user guide would make a good companion >> (i.e. separate) PEP. > > Until yesterday I would have said the same thing regarding the current > contents of PEP 394, but a surprisingly large number of the points in > the new user recommendations section actually came from the current > text of PEP 394 - they're down at the end of the recommendations > section, and when they were all in one list, it was easy to miss that > we'd crossed over from "Advice to platform publishers" into "Advice > for platform users". > >>> For Fedora for example, we think that dropping "/usr/bin/python" from >>> the repositories entirely would be too large of a compatibility break, >>> whereas we're comfortable with the idea that by 2020, it will be >>> reasonable to require that anything still running in "/usr/bin/python" >>> be hybrid Python 2/3 code, such that finally changing the default >>> won't cause too much immediate breakage (and for things that do still >>> break, the recommended fix will be code modernisation to get into the >>> hybrid subset prior to upgrading the OS). >> >> I like recommending /usr/bin/python be bilingual, but I’m wondering how >> you’ll enforce this, and what the implication is for running that at the >> command line. Again, that gets to the UI/UX issue. > > We're still working on the details (see > https://fedoraproject.org/wiki/User:Ncoghlan/Default_python_module for > my current notes), but what I'm currently leaning towards advocating > at the Fedora level is: > > - we declare "/usr/bin/env python" and other environment aware > invocations as already being effectively addressed, thanks to venv, > environment modules, conda, and other existing PATH based solutions > that change the interactive meaning of "python" > - by some suitable mechanism, we offer 3 different configurations for > the absolute "/usr/bin/python" path: symlink to /usr/bin/python2, > symlink to /usr/bin/python3, and "Not configured yet, here's how to > select your default interpreter" (as a matter of UX, I'm beginning to > think we'll need to make the last one an actual installable script in > its own right, as the default interpreter not found error from the > shebang handler isn't particularly informative)
that would only work, if the distribution has all uses of 'python' removed or replaced by python2. I don't see a re-use of the python command before it has stopped shipping in a distro release. Assuming that a next Debian release would be in 2019, not shipping the python command in 2021, and reintroducing it in 2023 as python3 ... Is this really worth it? Matthias _______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
