Mailman 3 August 2017 - Linux-sig

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Barry Warsaw Aug. 7, 2017

Aug. 7, 2017

On Aug 4, 2017, at 09:22, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > Where the idea of a "try to compile it as Py3 to see if that works, > but report an error anyway" script then comes in is as a potentially > better failure UX than the default "interpreter not found" from the > operating system's shebang processing. This makes me uncomfortable, because I think there will be cases, especially with smaller, one-off scripts, where compilation succeeds but where the code … [View More]

2 1

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Barry Warsaw Aug. 4, 2017

Aug. 4, 2017

Nick Coghlan wrote: > = Approach 3: add a magic script comment to opt-in to trying Py3 = > > This whole problem just doesn't feel like a per-script setting to me - > it feels like a system administrator setting, where they say either > "Yes, I am confident in my ability to debug errors arising from myself > and others trying to run Python 2 scripts on Python 3", or "I want to > preserve compatibility with older Py2 only systems for now, even if > that means running … [View More]

2 1

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Petr Viktorin Aug. 4, 2017

Aug. 4, 2017

On 08/02/2017 04:29 PM, Nick Coghlan wrote: > On 2 August 2017 at 23:57, Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> Another variant of that idea would be to have the default handler be >> something like Geoffrey Thomas's pythonmux project >> (https://github.com/geofft/pythonmux), and then patch >> sys.excepthandler to report the Python version executed when >> "sys.executable" isn't qualified as either Python 2 or Python 3 for >> easier debugging … [View More]of otherwise potentially cryptic error messages. >> >> If we did do that, then I'd skip the "pyversions" comment idea, and >> instead have the logic just be: >> >> - if only /usr/bin/python2 is present, use it >> - if only /usr/bin/python3 is present, use it >> - if both are present, use /usr/bin/python2 > > While I'm happy I at least brought it up, I still can't convince > myself to actually *like* this idea relative to the "compile it and > report on the results" approach combined with the ability to opt-in to > replacing that default script with a symlink to the desired version. Just compiling won't work -- consider `import pathlib` for example. This is UX, but for sysadmins (and other command-line users). Rather than trying to do what they mean, we should aim to synchronize their expectations and the reality. I'd rather have /usr/bin/python failing hard with a good error message than trying non-obvious heuristics. Avoid the temptation to guess. > This is due to what happens in a situation like Fedora's with various > mux behaviours: > > = Approach 1: impllcitly try Py3 = > > All the same problems as a plain symlink. If we were to patch > sys.excepthandler() to report the version when sys.executable == > '/usr/bin/python', then that UX tweak would apply just as well to the > symlink switching approach (maybe I should propose that as an > *upstream* change, and check for '/usr/local/bin/python' as well?). > > = Approach 2: default to Py2, complain if it is missing = > > Same effective consequence as defaulting to a custom script that > checks for Py3 syntax compatibility, just with a different more > implicit remedy ("Install Py2" vs "Install Py2 & make it the default > Python"). Also has the downside that you can't opt-in to making Py3 > the default instead. > > = Approach 3: add a magic script comment to opt-in to trying Py3 = > > This whole problem just doesn't feel like a per-script setting to me - > it feels like a system administrator setting, where they say either > "Yes, I am confident in my ability to debug errors arising from myself > and others trying to run Python 2 scripts on Python 3", or "I want to > preserve compatibility with older Py2 only systems for now, even if > that means running parallel Python stacks on my newer systems". [View Less]

2 1

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Barry Warsaw Aug. 2, 2017

Aug. 2, 2017

Nick Coghlan wrote: > Another variant of that idea would be to have the default handler be > something like Geoffrey Thomas's pythonmux project > (https://github.com/geofft/pythonmux), Yep, that's the project I was thinking of. I still like this proposal best, although I might quibble about some details (I'll do that on Thomas's GH project). It gives control to the right principles, i.e. the script author, or the person invoking the script (via environment variable), and doesn'… [View More]

1 0

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Nick Coghlan Aug. 2, 2017

Aug. 2, 2017

On 2 August 2017 at 23:57, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > Another variant of that idea would be to have the default handler be > something like Geoffrey Thomas's pythonmux project > (https://github.com/geofft/pythonmux), and then patch > sys.excepthandler to report the Python version executed when > "sys.executable" isn't qualified as either Python 2 or Python 3 for > easier debugging of otherwise potentially cryptic error messages. > > If we did do … [View More]

1 0

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Matthias Klose Aug. 2, 2017

Aug. 2, 2017

On 01.08.2017 01:40, Nick Coghlan wrote: > On 1 August 2017 at 03:47, Barry Warsaw <barry(a)python.org> wrote: >> On Jul 26, 2017, at 00:29, Nick Coghlan <ncoghlan(a)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 … [View More]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 [View Less]

2 1

Re: [Linux-SIG] Revisit of PEP 394 -- The "python" Command on Unix-Like Systems
by Barry Warsaw Aug. 2, 2017

Aug. 2, 2017

On Jul 31, 2017, at 19:40, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > > On 1 August 2017 at 03:47, Barry Warsaw <barry(a)python.org> wrote: >> On Jul 26, 2017, at 00:29, Nick Coghlan <ncoghlan(a)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” … [View More]>> >> 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”. After having reviewed the proposed PEP 548 PR, I still think we can keep 394 and target it specifically to platform vendors. > - 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) Another option is to make /usr/bin/python not actually *the* Python interpreter, but instead a wrapper that does $magic to get the right version. Several options have been bandied about over the years, and IIRC, Windows does something like this. Maybe it’s switchable based on a config file (both system and user overridable), or maybe there’s some other way. It won’t help start-up time <wink> but it could provide a better user experience. > In that light, it may make sense to more explicitly focus the PEP 394 > recommendations on *absolute* invocations that *don't* rely on PATH. +1 -Barry [View Less]

2 1