On Jul 31, 2017, at 19:40, Nick Coghlan <ncogh...@gmail.com> 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”.
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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
