On 12 November 2017 at 22:20, Paul Moore <p.f.moore@gmail.com> wrote:
On 12 November 2017 at 06:19, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
We still have to deal with the fact that basically every Unix environment is "advanced" in the above sense (the python2/python3 split). I don't have a solution for that (other than "upgrade to Windows" ;-)).
Provide the "py" command on linux and mac. And make it the default recommended way in the documentation.
+1 from me.
The current Python launcher is Window specific, and doesn't work on POSIX systems. So the first barrier here is "Write a py command that presents the same CLI on POSIX that the Python launcher does on Windows". The second problem is that even though we can add a "py" command to the python.org Mac OS X installers and have that take effect for new python.org downloads, there are a *lot* of people on Mac OS X and Linux that don't actually obtain their pre-built Python from python.org. While some of those would probably adapt and ship a new command fairly quickly (the cross-platform commercial redistributors, rolling release and 6-month cadence Linux distros, community redistributors like pythonz, pyenv, and homebrew), other important platforms wouldn't (most notably, LTS Linux distros). The fact it wouldn't actually solve the bootstrapping problem due to the update policies of various popular platforms then greatly reduces the incentive to work on the first part of the problem (i.e. actually creating a POSIX-compatible version of that CLI).
Well, not exactly. Do you do python -m venv, or py -x.x -m venv or pythonx -m venv ? Wait, it's not installed by default on debian.
Seriously? Debian don't provide venv in the standard Python install? That's just broken.
Yup. And RHEL/CentOS don't provide Python 3.x by default at all - you need to grab it via other means.
Virtualenvs are a hard tool to use for beginners.
Agreed. Genuine beginners just install Python, then use it. If they install extra packages, they want them to be available to all of their scripts.
Also agreed, but without them (or a functional equivalent, like `conda env` or `pyenv`), it's incredibly hard to get an arbitrary user on an arbitrary system to the point where all the following assumptions are satisfied: * the user is working at a command prompt (whether inside their IDE, or in an actual system shell) * the command `python` will run the desired version of Python * the commands `pip install` and `python -m pip install` will be essentially equivalent (aside from the differences when upgrading pip itself on Windows) and install packages into the desired version of Python * any executables installed that way will be executable from that command prompt * any Python import packages installed that way will be importable from a Python shell started in that environment (List of assumptions taken from https://github.com/pypa/python-packaging-user-guide/issues/396) Trying to drop any of those assumptions is problematic: * non-command-shell learning environments vary even more than command shells do * the `python` command has a much long history than any of the alternatives (including both `py` and `python3`), and third party guides reflect that * the `pip install` option really is nicer looking than `python -m pip install`, and it only has actual problems in the presence of multiple Python versions and when upgrading pip itself on Windows (plus: lots of third party guides recommend it, as do pypi.org project pages) * if `pip install devtool` doesn't let you run `command-from-devtool` in your command shell, that's thoroughly unhelpful * if `pip install dist-package` doesn't let you run `import library_from_dist_package` in your Python code, that's even less helpful It *would* be much nicer if a single user install of the Windows python.org installer met these criteria by default, though - while the `py` launcher is a good way of handling multiple versions (and nicely fills the role of handling file associations for Python file extensions), it isn't a particularly nice alternative to a properly configured user PATH on a machine with only one Python installation.
A lot of people on this list have forgotten their early years it seems.
Maybe. But the default beginner approach *does* have its problems, and guiding beginners to a better approach is a good idea.
We haven't forgotten our early years - we've just spent years (both individually and collectively) working on the problem of helping people get started with software development, and thus have a very good idea as to what *doesn't* work, as well as what *does* work. The latter list is currently fairly short: * having a friend or colleague walk them through it * "Install Parties", like those Django Girls runs (i.e. running a pre-tutorial event, specifically focused on getting a working environment set up) * highly prescriptive learning environments, whether online ones (like Grok Learning, trinket.io, PythonAnywhere, etc), or locally installed ones (like PyCharm Educational Edition, the Anaconda distribution, etc) Without the kinds of constraints suggested in the last option, there are too many potential starting points, and it isn't even possible to ask potential learners to self-assess what their starting point actually is, since it's a tech support problem where the first task is "assess the current state of the user's system" (hence the first two options). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia