Re: [Linux-SIG] Introducing a Python launcher for *nix?

On 8 Oct 2015 08:09, "Fred Drake" <fred@fdrake.net> wrote:
On Wed, Oct 7, 2015 at 4:17 PM, Piotr Ozarowski <ozarow@gmail.com> wrote:
If it's about letting users invoke any Python available (is pypy included here, BTW?), then why do you need -2 or -3 or worse: -X.Y?
I'm not sure what the original motivation for this proposal is; it appears to have been on a different list.
The first motive is consistent cross platform invocation - due to the way Python invocation on Windows is handled, commands like "python3 -m pip" and "python3.4 -m pip" don't work, and never will, and the differences in file system layouts exclude the use of absolute paths. The Python launcher for Windows *does* exist, though, so introducing a "py" script on the *nix side of things offers the opportunity to provide a truly cross platform Python experience modelled on the way that works: https://docs.python.org/3/using/windows.html#python-launcher-for-windows The second motive is to make it easy for individual users to switch to an alternative implementation like PyPy as their default interactive shell without impacting shebang lines and other automated invocations. I also want to allow users to make that switch without needing admin rights on their machine. The third motive is simply to make -m invocations shorter ("py -m pip" rather than "python -m pip").
The notion that a script is going to figure out which Python is the right one just seems pretty strange to me. When developing an application, I know exactly which Python I want to use, and build that application with that Python to begin with.
You're already a professional developer, though, rather than someone learning about the command line and filesystems as part of learning to program in Python.
Any user-facing scripts get the right sh-bang line to begin with. If I'm building a library, I'm going to do things with several versions (tests can be driven with tox, for example), but library users are going to know what version of Python their application calls for, and they'll use it.
No, they don't necessarily know this. If folks don't want to take my word for that, volunteering as a helper at a Software Carpentry bootcamp, a Python for Young Coders workshop or another community event that introduces children or adults to Python programming highlights just how radically wrong these kinds of assumptions are in the context of people learning to program, especially when instructors are needing to cope with a mixed audience of Windows, OS X, and Linux users.
I may be missing something pretty obvious to many, though. My approaches to building an application don't appear to be commonly applied in Python environments.
Yeah, I failed to convey that the main intended beneficiaries are future newcomers to Python, and the folks that are themselves using Linux or OS X, but need to provide instructions that also work on Windows. Cheers, Nick.
-Fred
-- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein _______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
participants (1)
-
Nick Coghlan