On 15 March 2016 at 12:01, Paul Moore firstname.lastname@example.org wrote:
On 15 March 2016 at 11:25, Oscar Benjamin email@example.com wrote:
AFAICT the default behaviour of the Windows installer does not add Python to PATH. Correct me if I'm wrong as I haven't used it myself for some time but when I tell my students to "install Python 3.5" and then to type "python" in the terminal a lot of the Windows users come back to me with PATH problems (specifically that python was not added to PATH).
I would have thought that is relatively easy to resolve. A pain to have to do in a classroom environment, certainly, but manageable.
It's easy enough to resolve if they bring their computer directly to me. It's less easy to resolve by email. It just becomes something many students waste time trying to fix when they're not yet ready to meaningfully learn from the experience.
The reasons Python is not added to PATH are something that has been debated over and over again on various lists. As far as I know, neither option is ideal, but "not on PATH by default" is typically seen as the least likely to fail in confusing ways.
Why would we not want python on PATH? If it's because of having multiple installed Pythons then maybe it's possible to improve the installer so that it gives the user a selection of which is on PATH and adds it by default if it isn't already there. A simple rule: "if Python is not on PATH then the installer assumes that the user wants to add it" would suffice.
You could (relatively easily) write a small Windows Scripting Host script to locate the version of Python you wanted people to use via the registry, and add it to the front of PATH. That would need elevation to work, of course, but would give a known-good starting point.
I would probably have more success telling them to tick the "add to PATH" box on the installer :)
(A proportion would get it wrong whatever I say though)
On Unix, tell people just "run python3".
It's not always a question of telling people what command to run. The particular scenario that just came up is that of a C program with a Makefile and a Python script that tests the output of the C program. So I give the students a skeleton project that looks like
proj-1.0.zip/ proj-1.0/ projmain.c Makefile tests/ runtests.py
The idea is that they should fill in the C code to complete a program. The runtests.py script runs their program testing input/output combinations and scores how much they have completed.
Now in Makefile I have
test: proj.exe python tests/runtests.py
So the students can run "make test" to rebuild their project and run the tests. The question is how to set this up when "python" is not guaranteed to be on PATH and could be many different versions of Python. ATM I have to exhaustively test all combinations of Python 2.7 and 3.5 and Windows, OSX and Linux and then I still hit up against problems because the way in which they've installed Python is not the same as the machines I tested on.
Testing the output of a subprocess in 2/3 compatible code is painful because it comes out as bytes in 3 and str in 2. Really the only necessary incompatibility that I should need to deal with in this scenario is Windows line endings. All the others like which version of python will run, whether or not python is on PATH and the 2/3 incompatibilities are all down to Python rather than the inherent variabilities of the OSes.