Make py.exe default to Python 3
The "py.exe" wrapper on Windows runs the latest Python version available on the user's PC, but it prefers Python 2 if the user has both Python 2 and 3 installed. With Python 3.5 being released, is it not about time that we switched that default to always prefer the latest version available? For scripts, users can always specify a shebang line, exactly as on Unix. For interactive use, people who prefer Python 2 simply have to create a py.ini file saying [defaults] python=2 At the moment, someone using Python 3 exclusively can use "py" to start the Python interpreter - and with the changes in the Python 3.5 installer, defaulting to a per-user install that's not on PATH, this is often the most convenient approach. But if that person installs Python 2 (say, to test some code on that version) py.exe silently switches to using Python 2. And it does so regardless of whether you specify "make this the default Python" in the installer. It seems to me that this behaviour is much more unexpected than the equivalent of a Python user installing Python 3 (py.exe switches to Python 3, but that's "obviously" the latest version). So I suggest that in Python 3.6, we (finally) switch py.exe to run the latest version of Python on the user's machine *regardless of the major version*. This will be a compatibility break, but arguably no more serious than the fact that if the user installs Python 3.6 and puts it on PATH, then "python.exe" now points to Python 3.6. To cover people just installing Python 3.6 for testing, we could check in the installer and if the user only currently has Python 2 installed, has no py.ini, and doesn't select "make this my default Python" for Python 3.6, then we write a py.ini defaulting to Python 2. I don't know if that's worth the effort, it depends largely on how many people will be affected by the change. Paul
On 8 March 2016 at 11:22, Victor Stinner <victor.stinner@gmail.com> wrote:
I don't know. Personally, I don't like the versioned executables (will we get a py4, py5,...?) but that's just a personal preference. I believe that with an unversioned executable it should use the latest version by default, and the point of my email is that I think we're now at a point where special casing Python 2 is unreasonable, particularly on Windows where there is no tradition of a "system Python" which needs to be Python 2. If someone *else* wants to propose replacing py.exe with py2.exe and py3.exe then they can do that (and I'll be -1 on that proposal). You don't mention the fact that an unadorned "python" command on Unix typically invokes Python 2. As far as I know the only reason that was needed was because system Python scripts were written that way, back before Python 3 was around, and couldn't be updated to be Python 3 compatible. That reason doesn't apply on Windows. And on Windows, "python" has always referred to the currently active version of Python, whether 2 or 3. tl; dr; I'm against making the unversioned name "python" (or "py") forever mean Python 2. There are justifications for it on Unix, but none of those apply on Windows. Paul
On Wed, Mar 9, 2016 at 12:17 AM, Paul Moore <p.f.moore@gmail.com> wrote:
https://www.python.org/dev/peps/pep-0394/#exclusion-of-ms-windows On Unix, yes, but not on Windows. +1 for making py.exe now default to Python 3. ChrisA
On 03/08/2016 01:11 PM, Alexander Walters wrote:
Which is still asking for a change from what happens now; i.e. if 3.3 is installed first, then 2.7, py.exe will default to 2.7. I agree whichever is first installed should be default; I also think installer should have an option to change the py.exe default to the version being installed. -- ~Ethan~
On 08Mar2016 1334, Alexander Walters wrote:
"First installed" is a very difficult proposition, especially if you want versions of Python pre-3.6 to participate. "Last installed" is slightly better, though not easy to do without triggering systems that detect corrupted installations. Personally I think "latest version" is the best default (compared to the current "latest 2.x version"), so I'm +1 on removing the assumption that "PY_PYTHON" is "2" by default. Users can change their own default with any of the mechanisms described at https://docs.python.org/3/using/windows.html#customization Cheers, Steve
On 8 March 2016 at 22:00, Steve Dower <steve.dower@python.org> wrote:
Also, any dependency on installation order gets *very* messy if someone installs and uninstalls various versions. What does the default become if I uninstall the version that was previously the first (or last) installed? Would we need to keep details of precisely when everything was installed?
Latest version has the additional advantage of being essentially the current behaviour, just with the special case of "but prefer Python 2 over Python 3 if both are present" removed. (Note that technically the current rule is not simply "latest 2.x version", as if the user only has Python 3 installed, the latest 3.x version is used). The only other option I can think of is "use the one the user selected as the default Python (i.e., introspect the association for ".py" files) but even then we need a default default (!) for people who don't select any default Python. It's also messy to implement. And it's a bigger change from current behaviour.
Users can change their own default with any of the mechanisms described at https://docs.python.org/3/using/windows.html#customization
Absolutely. This should *only* apply when there is no user customisation - and it needs no further configurability, because the current methods are perfectly sufficient. Paul
How about the better option: No default preset default.. Make the user pick every time it's installed. Or the best option of them all: call Python 3... python3.exe and the shell launcher py3.exe. Or stop it with the launcher. I cannot think of many situations where a non-technical user would install the base python, and run modules. Most user applications ship their own interpreter. In enterprise situations, you would want WAY more control of what python you are using than py.exe offers. So who is py.exe for? So i am changing my -1 from changing the default behavior to -1 for its continued existence. On 3/8/2016 17:18, Paul Moore wrote:
On Wed, Mar 9, 2016 at 2:59 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Have a read of PEP 397 if you want to know why the launcher exists. https://www.python.org/dev/peps/pep-0397/ ChrisA
It modifies the windows registry to set a file association, which is a pain when you want double clicking a python file to open a text editor. So you have to change file associations, which was made really painful in recent versions of windows. On 3/8/2016 23:19, Ethan Furman wrote:
On Tue, Mar 8, 2016 at 11:06 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Linux users are used to being able to type "./script.py" on the command line and have the shebang tell the OS which version of Python to use. Windows doesn't support that because it instead works off of associating the file extension globally with an individual program, so ".py" can only be associated with a single executable, which is unworkable if you have both python2 and python3 scripts. py.exe solves that problem. So unless you have an alternative solution to enable Unix-like script launching with multiple Python versions from the command line, proposing to eliminate py.exe is a non-starter, at least with me. On Tue, Mar 8, 2016 at 11:22 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
So add an option to the installer to not set that file association. It's been a while since I installed a Python on my Windows machine, but IIRC that option may already be there (I could be mistaken, though).
On Tue, Mar 08, 2016 at 11:32:34PM -0500, Alexander Walters wrote:
Windows is not *nix. Supporting *nix idioms should not be a priority.
Python is over two decades old and we're up to version 3.5. You can hardly call this "a priority". It's been a long time coming. Besides, it surely depends on whether or not the idiom in question is valuable. Windows, and DOS before it, has copied many idioms from Unix over the years, as Unix/Linux have copied from Windows. For better or worse.
Then you should submit a bug or enhancement request to have that fixed. -- Steve
On Tue, Mar 08, 2016 at 11:22:19PM -0500, Alexander Walters complained about py.exe:
Sounds like your real beef is with Windows, not py.exe. As a programmer, couldn't you script something to change the file association and make it easier? When the pain of doing something gets greater than the pain of writing a short script, that's what I do. If you're having this problem, perhaps others are too, and the installer could make the file association change optional? -- Steve
On 9 March 2016 at 14:06, Alexander Walters <tritium-list@sdamon.com> wrote:
Volunteers don't generally donate their time to solve problems they don't have (and employers don't typically donate their employees' time to solve problems they or their customers don't have), which means "I don't personally have that problem, so I deny its very existence" is almost never a compelling line of argument in a community-driven open source project. In this case, we needed a cross-platform way for Python 3 scripts to indicate they were Python 3 only, and Python 2 scripts to indicate they were Python 2 only. *nix already had a way to indicate that via shebang lines, so it was natural to make that existing solution also work on Windows, rather than inventing something Windows specific (which would rather defeat the "cross-platform" objective). The fact that the chosen implementation strategy also made the "py" launcher usable at the command line was more of a side effect than the primary purpose of the exercise. In that regard, I think the meaning of "Make py.exe default to Python 3" as proposed in this thread needs to be spelled out more explicitly. If the proposal is to change the default behaviour for: * launching the interactive interpreter * running scripts without a shebang line * running scripts with an unrecognised shebang line then I think it's reasonable to switch all those to default to the newest CPython runtime on the machine, regardless of whether that's Python 2 or Python 3. However, if the proposal is also to change the handling of the following shebang lines: * #!/usr/bin/python * #!/usr/local/bin/python * #!/usr/bin/env python * #!python then I think those should continue to be handled in a manner consistent with PEP 394 (and as PEP 397 currently specifies): as referring to Python 2 (unless PY_PYTHON explicitly says otherwise or only Python 3 is available). Independently of the main topic of the thread, it does sound to me like there may be a valid enhancement request for the Windows installer to add a "Repair" mode that allows some of these settings (like adding or removing the file association) to be changed post-installation. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Mar 9, 2016 at 4:32 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Agree with both of these points. AIUI the original proposal was solely about the first half, with no recommendation of change to the second. What does py.exe do with a "#!/usr/bin/python" if the only Python installed is 3.5? Does it run it under 3.5, or error out? ChrisA
On 9 March 2016 at 05:39, Chris Angelico <rosuav@gmail.com> wrote:
My original post was prompted by interactive use, so I hadn't thought of the #!/usr/bin/python case. I can see Nick's point here. But...
What does py.exe do with a "#!/usr/bin/python" if the only Python installed is 3.5? Does it run it under 3.5, or error out?
I believe it runs Python 3. I no longer have a system with just Python 3 on, so I can't quickly test this, but I'd be surprised if it failed, based on my experience. And Nick noted that using Python 3 if it's the only one available is what the PEP says. So with regard to changing the behaviour of shebang lines I see the following points: 1. Compatibility with Unix, where an unadorned "python" in a shebang means "python 2". I personally hate this behaviour, and view it as a nasty wart of Unix. So I'm not in favour of promoting it on Windows (IMO, if you're writing scripts for publication, be explicit about whether you want Python 2 or 3 - an unqualified "python" in a shebang line should be only for cases of "I don't care, my code works for both" or purely personal code). But compatibility. 2. From what I recall of the py.exe code, implementing the exception only for shebang lines would be more complex than the current code, so I'd prefer there to be a demonstrated benefit. Unfortunately, it's really hard to know how much the feature is used. I only use it myself for personal scripts (and not much even then, tbh, because Powershell is weird with file associations). 3. On Python 3 only systems, the current behaviour isn't consistent with Unix anyway. I don't disagree with limiting the change to not affect unversioned shebang lines, but I'm not sure how much effort I'd personally be willing to put into special-casing that. We can see on that one when I start to look at the actual code, I guess... Paul
On Wed, Mar 9, 2016 at 3:47 AM, Paul Moore <p.f.moore@gmail.com> wrote:
I agree with Nick that Python 2 compatibility should be maintained for virtual paths in shebangs. I think a straight-forward solution is for locate_python() to gain a "virtual_mode" BOOL parameter, which is TRUE only when processing a virtual shebang, i.e. when called from maybe_handle_shebang(). For example, when wanted_ver is empty, locate_python would search the following sequence: configured_value = get_configured_value(config_key); if (configured_value) result = find_python_by_version(configured_value); if (result == NULL) result = find_python_by_version(virtual_mode ? L"2" : L"3"); if (result == NULL) result = find_python_by_version(virtual_mode ? L"3" : L"2"); This change works for me with various combinations of enabled PythonCore registry keys, PY_PYTHON values, and shebang lines. Note that the behavior of the plain "#!python" virtual shebang gets lumped in with virtual Unix paths, but I don't know why anyone would add this shebang without a target version.
On 9 March 2016 at 12:49, eryk sun <eryksun@gmail.com> wrote:
Thanks for reviewing the code for me - that does indeed look perfectly straightforward so I'm OK with following Nick's suggestion here. As there's not been much in the way of resistance to the proposal, do people think it requires a PEP? I plan on letting this thread run its course either way, it's just a matter of whether the next step should be a tracker item or a PEP. Thanks, Paul
On 09/03/2016 13:21, Paul Moore wrote:
I do not believe that this needs a PEP, a tracker item should be fine IMHO. We should just ensure that the original authors of the PEP are aware, as missing out their opinions would be a disservice to the Python Windows community, as small as that may be when compared to *nix. Just my £0.02p worth. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Thu, Mar 10, 2016 at 8:20 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Given that this is basically a Windows-only change, it doesn't matter how large or small the Windows community is - they're the people who primarily matter :) If someone proposed a change to the way things are done on OS/2, it'd be worth getting the opinions of both of the Python OS/2 users... :P ChrisA
On 9 March 2016 at 21:25, Chris Angelico <rosuav@gmail.com> wrote:
Although it is a change to Windows-only I think it is important to think about the consistency between the way that this works on Windows compared with other operating systems. Inconsistencies here can be awkward for novices. Allow me to spell out my scenario... I teach a couple of University programming units in which students learn to program in Python, C and Java. The cohort for these units this year was 160 students. I often find myself giving the students instructions such as you can run this script I've given you with $ python myscript.py Now imagine that you've given that instruction to 160 students mostly using Windows and OSX (and a few Linux users). I find it very annoying that this could invoke Python 2 or 3 depending on the OS etc that the students are using. py.exe should solve this since I can write py -3 and then (I assume) it would lead to an error if no Python 3 version is available. However that doesn't work on OSX or Linux. Okay so maybe we should just use the shebangs. I can explain to all my students what shebangs are and instruct the OSX students to set the executable bit. Then I can say so just run $ ./myscript.py however on Windows this uses file associations which is flaky. In the past I've seen bugs where e.g. input/output redirection didn't work for scripts run in this way. It also may not work in myriad other contexts where a command line may be used. One example is from Makefiles. So when my students are working in C I can give them a Python script that will test the output of their C program and I can tell them to add this to their Makefile e.g.: test: myprog.exe ./myscript.py At this point (on Windows) various failures are possible. If make simply calls CreateProcess it fails since myscript.py isn't an exe file (I believe it also accepts .bat files but does not observe file associations). If make inspects the shebang it may come to a very different conclusion from the one that py.exe would have (e.g. that python3 does not exist since it is not on PATH). Over time I've seen this go wrong in a number of ways and have ultimately concluded that anything involving using file associations is fragile. Personally I would really like it if we could have improved consistency across OSes when it comes to invoking Python. So I would really like it if we can either have py (and maybe py3) *everywhere* or if that's not possible find some solution that does work everywhere. Can we have a single command line that guarantees to run Python 3 (or error out)? -- Oscar
On Mar 12, 2016, at 15:38, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
What if Python 3 created a symlink (or, for non-NTFS drives, a copy) of Python.exe named Python3.exe? Would that be sufficient for you to just tell your students to run: $ python3 myscript.py At any rate, this seems to be a separate issue from the one this thread is about. It's already true that py.exe is Windows-specific; no change to what it does is going to make the same command lines work on Windows and *nix. Only some new proposal (add a py command for Unix, add python2 and python3 links for Windows, make Python.exe itself a dispatcher as Apple's /usr/bin/python is on Mac, ...) is going to help you. So you might be better off creating a new thread instead of adding on to one that's mostly been resolved and a lot of people have stopped reading.
On 13 March 2016 at 04:09, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
At any rate, this seems to be a separate issue from the one this thread is about. It's already true that py.exe is Windows-specific; no change to what it does is going to make the same command lines work on Windows and *nix. Only some new proposal (add a py command for Unix, add python2 and python3 links for Windows, make Python.exe itself a dispatcher as Apple's /usr/bin/python is on Mac, ...) is going to help you. So you might be better off creating a new thread instead of adding on to one that's mostly been resolved and a lot of people have stopped reading.
Agreed. Just to summarise the final state of this thread, the consensus seems to be: 1. For interactive use, make py.exe launch the latest version installed on the machine, without special-casing a preference for Python 2. 2. For shebang lines where an unversioned name is used, retain the current behaviour (for compatibility with Unix). 3. When the user explicitly chooses a version, or has configured the launcher via the ini file or environment variables, no change to current behaviour. 4. The change is small enough that it doesn't need a PEP. On that basis, I'll make some time to brush off my C skills and raise a tracker item, targeted at Python 3.6. As far as I know, there's no special exemption for new features in the launcher being backported to older versions of Python, and there's no "standalone" launcher installer, so this change will only affect people who install the launcher via the Python 3.6 or later installer. Paul
The past and future of Python (a little off topic, sorry :): Python 2: $ python myapp.py Python 3: $ py myapp.py Python 4: $ p myapp.py Python 5: $ myapp Python 6: Executing Python applications will be natively built into every OS, and the problem of a cross-platform way to conveniently distribute and run a Python *application* will be magically solved. - Koos
On 13 March 2016 at 11:39, Paul Moore <p.f.moore@gmail.com> wrote:
I guess it's maybe just because this thread has made me realise that py.exe has changed purpose with respect to what it seemed (to me) to be before. When I was using Windows I used to always arrange for python and python3 to be available on PATH and I only used the "py" command as a way of explicitly selecting a particular non-default Python version. The idea that the default for py.exe needs to be python 3 suggests that people are now using "py" as the primary command line invocation of Python on Windows. I think is unfortunate as it takes Windows off in a different direction from every other OS. That intention wasn't the impression I had of PEP 397 at the time. -- Oscar
On 14 March 2016 at 17:18, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Indeed, it wasn't, and I would have always said that people should put the version of Python that they want on PATH. Indeed, I still do that. I don't think there's any "official" change in policy, nor is there a groundswell of people using py.exe to invoke Python on the command line. But PATH management remains messy and is probably even more so now that per-user installs are the default (per-user PATH entries go after system PATH entries on Windows, which makes the default behaviour complex to describe, there's no way around that). So using py.exe (which is always on PATH, and which gives access to any Python) is possibly a more attractive option nowadays. I've personally been experimenting with using it, and I've found that the "Python 2 takes priority" behaviour is suboptimal for my interactive use - this thread implies that I'm not alone in that. So I'll be following up with a change to improve that default. That's all, as far as I'm concerned. But as for "the canonical way to run Python" - much less "the canonical way to ensure you're running Python 3 (or 2)" - I don't think there's any such thing, and honestly there never has been since Python 3 came into existence and a proportion of the community needed "python" to continue referring to Python 2, even though a newer version had been released. If you (or anyone else) wanted to put together a proposal for such a cross-platform standard way of launching specific Python versions, then by all means go ahead. I can imagine it would be immensely useful to have such a thing in a teaching context. Personally it would be of no value to me, though, so I'm not going to be interested in such a proposal. I apologise if I gave the impression in this thread that there's any sort of "official" change in advice on how to launch Python. As far as I know, there hasn't been. Paul
On 15 March 2016 at 09:01, Paul Moore <p.f.moore@gmail.com> wrote:
It's still "python" - that works regardless of version on Windows (with a suitably configured PATH), in virtual environments and in pyenv and conda environments (and probably in Enthought Canopy as well, but I haven't checked that). The only places where it doesn't work are: * Windows without a properly configured PATH (and without a tool like vex or conda) * accessing Python 3 on *nix systems (without a tool like vex, pyenv or conda) On the *nix side of things, the long term objective is to get "python" to a point of being usable for the latter case, but there's still a lot of other things to be done before that's a realistic option (e.g. migrating system packages over to using their own dedicated binary or symlink, so "python" can be switched to point to something else without affecting system services). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 15 March 2016 at 04:47, Nick Coghlan <ncoghlan@gmail.com> wrote:
You don't need to apologise in any case but that's not what I meant. Also I'm not disagreeing with your proposal to change the default behaviour of py.exe. It's not so much "official policy" that I was lamenting but just the way things have evolved. I don't think that anyone really intended to reach the current situation where the different OSes have diverged and there's no longer a clear uniform command line to run a Python script.
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).
Well that would initially improve things but what happens when python 4 comes around? Really I think that for something like this having major-versioned executables is a good idea. It's just a shame that it wasn't done consistently. -- Oscar
On Mar 15, 2016, at 04:25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Nothing. It'll be called just "python" on both platforms. Just like when Python 2.0 came out, it was just called "python", not "python2", and was no more incompatible with 1.5 than 1.5 had been with 1.4. Python 3 was a once-in-a-lifetime, or at least once-in-a-generation, thing, not a plan to overhaul everything once/decade. (At least that's the impression I get from the PEPs, Guido's blogs, other dev's blogs, and the mailing lists.) The only way I can imagine Python 4.0 being incompatible is 3.9 is followed by 3.10 and somewhere in the distant future the memory of the 2.5->3.0 transition has faded (or the *nix environment has changed) to the point where a similar 3.14->4.0 seems like a good idea.
On 15 March 2016 at 11:25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
I would have thought that is relatively easy to resolve. A pain to have to do in a classroom environment, certainly, but manageable. 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. 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. On Unix, tell people just "run python3". Having versioned executables available on Windows might be helpful, but only a little bit as they still wouldn't be on PATH. Paul
On 15 March 2016 at 12:01, Paul Moore <p.f.moore@gmail.com> wrote:
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.
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.
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. -- Oscar
On 15 March 2016 at 12:38, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Why would we not want python on PATH?
You should probably go and hunt out previous discussions (your best bet is likely the python-dev archives). They were pretty extensive, and I'd likely get details wrong if I tried to summarise.
Certainly it's only an issue if the user has multiple Pythons. Of course, this can include things like conda or ActiveState Python, or programs like Lilypond that bundle Python. Some issues I recall: 1. You can improve the Python 3.6 installer, but if the user installs Python 2.7 after 3.6, they'll get the old installer with that. And conda may do something else altogether. So fixing just one installer doesn't remove the issue. 2. User installs can only add to the user part of PATH, which the OS adds *after* the system PATH. So if you do a system install and a user install, the system install will *always* take precendence, regardless of what you ask for. This is particularly problematic as Python 3.5+ defaults to a user install. 3. When you ask for a new Python to be added to PATH, should previous ones be removed? If you then uninstall the new Python, will you be left with nothing on PATH? I've seen the view expressed that PATH is for the user to manage and installers have no business changing it at all. While I'm not sure that many people who write installers would agree with that, having dealt with my own share of messed up PATHs caused by installers, I can certainly sympathise with that position. Paul
Le 15/03/2016 14:12, Paul Moore a écrit :
Yes, but you are able to deal with those issues. And they happen rarely. Failing to run Python in the terminal occurs every single introduction course I give. Every single one. And without help, a beginner will have trouble solving it because it's hard to search in Google for something you know nothing about. So some of them, the ones that can understand English and see the value of looking it up for hours, may solve it. The other ones will give up. Another problem is the gigantic time and energy wasted for this : I have to tell about this box in every course, write it down (with screenshot) in every tutorials, mention it in every videos I do. And yet, yet! People still come to me, write comments, emails, not understanding why typing "python" in this big black windows doesn't work. And then, you have the worst case scenario. The one where the person, a bit tech saavy, tried to edit the PATH manually in this tiny, unresizeable window, and messed it up. Now, try to diagnose that over skype, or on a forum, or on twitter... I already made the choice to spends hours of my life helping people with Python, but I wish I could spend it on explaining how they can make their computer do nice stuff, not on making sure they tick boxes.
On 15 March 2016 at 16:50, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
Yes, but you are able to deal with those issues. And they happen rarely.
Agreed. One of the issues with the debates about whether to add Python to PATH by default was that the people involved - the Python core devs - were not at all typical users (they probably have multiple Python versions installed, and they are comfortable with technical details like PATH management, etc). As Nick said, we need people like educators, with real experience of what the stumbling blocks for new users are, to provide a more realistic justification for the change. Maybe someone in this discussion could raise a feature request on bugs.python.org suggesting this gets changed? Paul
On Tue, Mar 15, 2016, at 13:47, Paul Moore wrote:
I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.
On 15Mar2016 1231, Random832 wrote:
This is one of two solutions I'd be comfortable with. The other is to rename "py[w].exe" as "python[w].exe". PATH is used to resolve system DLLs and common commands. Over time, better security features are being added for core system components, but it is still possible to hijack programs this way. It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change. In my experience, it's mostly Python 3.x turning into 2.7 because a keen Python developer meets a jaded one and gets told they should only be using old things... Windows Installer does not have a nice mechanism to handle ordering of PATH entries or detecting existing ones, unless all the installers are cooperating. It certainly doesn't handle any case here where users may add/remove Python installs whenever they like. This is why the launcher was created. I have always been -1 on modifying PATH by default, and trading an early problem for a later, more subtle, problem does not convince me. And I say this as someone who has taught classes of undergraduate students how to use Python on Windows, and had to deal with the same problems. I'm not trying to lord it over the installer just because I'm the one who wrote and maintains it - if someone else files a patch and one of the other committers puts it in, so be it. But I'd much rather (a) make users choose up front to have an environment where "python.exe" is easily accessible, or (b) make "python.exe" consistently launch the right version. Cheers, Steve
On 15 March 2016 at 20:58, Steve Dower <steve.dower@python.org> wrote:
I'm very conscious that as an experienced user, I don't actually care what the installer does, as I'll reconfigure things the way I want anyway. However, in my opinion, the worst part of having a "Python command prompt" start menu item is that it assumes everyone wants to use cmd.exe. But there's also powershell users to consider. Furthermore, having a command prompt that does what you want doesn't help people who want to run Python from something like a scheduled task. Of course, for Python it's no issue, as you can use the full path to the interpreter and that's fine - I learned my dislike of this technique from Visual Studio, where it's not that simple... I'm not sure renaming py.exe as python.exe is such a good idea either. I don't have a strong reason to give, just a suspicion that the subtly different arguments, and the fact that it (by design) doesn't respect PATH, make me concerned that it'll cause even more subtle issues than the current approach. Also, it's not possible for users with their own approaches to "opt out", where a PATH setting can be altered by the user. Anyway, as I say, I'll probably stick to doing things my own way whatever happens. Paul
On Tue, Mar 15, 2016 at 3:58 PM, Steve Dower <steve.dower@python.org> wrote:
I've wondered about allowing the launcher to determine the Python it should invoke by its own name. That is, if the launcher is named 'python3.exe' it should behave as 'py -3'; 'python2.7.exe' should behave as 'py -2.7'. I wrote a patch to that effect a year or two ago but never got it polished up enough to submit. What about doing this, and at launcher install time (or at 'repair installation' time) create links for each found Python (and python2/python3 if they exist)? -- Zach
On 15Mar2016 1414, Zachary Ware wrote:
Very tough to automatically install for all found Pythons like this through an MSI, but if the not-found exit code is 9009 then there's no reason we can't just install copies for as many versions as we like. What would also be nice is "activatepyX.Y" scripts (presumably in both .cmd and .ps1 formats) that would modify the current PATH. I started a PEP a while back proposing these but never finished. If we start adding this many files I'd also want to move the launchers into their own directory (probably "C:\Program Files\Common Files\Python\Launcher") and add that to the global PATH. As long as we strictly control what files are in there, I have no problem with adding it - we just don't want any random DLL or EXE getting in there. Cheers, Steve
On Mar 15, 2016, at 13:58, Steve Dower <steve.dower@python.org> wrote:
But isn't the whole point here that we want novices to be able to treat python and/or python3 as a "common command", just like py? That implies either putting the executable in an existing PATH directory, or adding the executable's directory to the PATH (or, of course, renaming py, as you suggest, since that already gets put into an existing directory).
It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change.
If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow or whatever and get a quick answer. And that means we don't have to solve the conflict problems, the uninstall leave-behind problems, etc. for multiple pythons.
On Wed, Mar 16, 2016 at 8:29 AM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
please no -- it should be easy and obvious to "upgrade" python -- i.e. the last one you installed is what "just works". If the default does that, then a non-defautl option to not override the existing one would be nice: """ Warning: there is an existing python installed on this system: check here if you want to continue to have the old version be used as the default. Leve the box unchecked if you want the version to be the new default. """ or something like that. After all, what do people expect when they have MSWord version X, and then install MSWord version X+1 ? They expect that when they run Word after that, they'll get the new version. Is this going to surprise anyone??? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Mar 16, 2016, at 10:22, Chris Barker <chris.barker@noaa.gov> wrote:
Last time I did that, I ended up with Office 2007 in a completely separate directory from Office 2003, with their own Start Menu folders. The one under "Office" was still 2003, but there was a new one under "Microsoft Office" that I had to find. And Win-F "winword" still ran 2003. And .doc files were still owned by 2003 (but docx by 2007). And all of my system templates and most of my addons from 2003 weren't available in 2007 until I manually reinstalled them for it. And so on. I don't think anyone expects that with Office. There are other kinds of apps where people _do_ expect it. For example, if you have TuneUp 2.4.3 and then install TuneUp 2.5.7, when you run a TuneUp (whether via the Start menu, or Win-F, or because you had the "auto-start with iTunes checkbox on, etc.), you'll definitely get 2.5.7. But that's because 2.4.3 no longer exists on your system. I don't think we want a Python 3.6 install to automatically uninstall or overwrite 2.7, or vice-versa. Which means it's like Office, not like TuneUp. Installing two Python versions on the same machine is always going to require some kind of management by the user.
The uninstall problem is actually that "python" would stop working completely in that case, and it's not necessarily obvious why or how to fix it. The leave-behind problem doesn't really matter as the directory is not searched if it doesn't exist, but we also don't leave behind entries added by the installer. A user who customizes their own PATH will obviously need to manually remove the entry, but that's a manual action both times so I don't see any concern there. At one point I was trying to convince the Windows team to add a global "python" command to all Windows installs (probably 10 and later - we don't backport stuff like this, but it could be a manual install) that would act like the py.exe launcher but also automatically download Python if you didn't have it. What would people think if I got that to happen? Top-posted from my Windows Phone -----Original Message----- From: "Andrew Barnert" <abarnert@yahoo.com> Sent: 3/16/2016 8:30 To: "Steve Dower" <steve.dower@python.org> Cc: "python-ideas@python.org" <python-ideas@python.org> Subject: Re: [Python-ideas] Make py.exe default to Python 3 On Mar 15, 2016, at 13:58, Steve Dower <steve.dower@python.org> wrote:
But isn't the whole point here that we want novices to be able to treat python and/or python3 as a "common command", just like py? That implies either putting the executable in an existing PATH directory, or adding the executable's directory to the PATH (or, of course, renaming py, as you suggest, since that already gets put into an existing directory).
It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change.
If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow or whatever and get a quick answer. And that means we don't have to solve the conflict problems, the uninstall leave-behind problems, etc. for multiple pythons.
On 16 March 2016 at 18:06, Ethan Furman <ethan@stoneleaf.us> wrote:
Agreed it would be awesome. I see no reason to bother with 2.x, though. If the user knows enough to know they want 2.x they can download and install it. Otherwise just give people the latest and greatest Python. Paul
Absolutely! I have the same experience in my classes. The reality is that MS has not updated the GUI for setting PATH since Windows 3.1 as far as I can tell. It sucks. So we really, really, want this to Just Work for newbies. Yes, things get complicated with multiple versions of Python, etc, but that is going to require understanding s fair bit about PATH et al. No matter how you slice it. Let's be sure the simple case is easy and obvious. -CHB
On Tue, Mar 15, 2016 at 9:59 PM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
The reality is that MS has not updated the GUI for setting PATH since Windows 3.1 as far as I can tell. It sucks.
Actually, Windows 10 (or at least Windows 10 with the latest updates) introduced a much, MUCH nicer interface for PATH editing. Here's a screenshot: http://snag.gy/WH4Oj.jpg With this interface, one can edit individual entries (an edit to the Python 2.7 \Scripts folder in the system PATH is in progress in this screenshot), use the browse button to select new folders via GUI, tweak the order of the list, easily remove entries, and so forth. The details of the plaintext version of PATH that one would use at the command prompt are hidden behind the "edit text" button. I recently performed a massive cleanup to my PATHs after discovered this new interface, and it was really easy.
Le 16/03/2016 03:10, Jonathan Goble a écrit :
I noticed that last month, and it's a good thing, but universities and companies are not going to upgrade for years (if they do it at all). Most of my students, when using windows, are using Windows 7. A few is running Vista or 8. Sometime, I meet some XP (yeah, I know). I only met one using Windows 10, and it was his own laptop. Plus fixing a way to fix a problem is, while improving the situation, probably not the best way to look at the situation.
Finally! and after only 20 years. Great to see that. But we will be dealing with pre Windows10 for a a good long time :-) Plus fixing a way to fix a problem is, while improving the situation,
probably not the best way to look at the situation.
well, it does change teh burden teh choice is between auto-setting PATH, and requiring people to set/adjust it themselves -- each has it's advantages. And how easy it is to adjsut it yourself does effect the trade-off. But as we will be supporting Windows pre-10 for a long time, we still need it to "just work" for less sophisticated users without them having to mess with PATH. As in: If someone installs a version of python with defaults, they should then get that version when they type "python" (or maybe "py") at the command line. If they want something other than the last one they installed, then they'll have to mess with PATH or other configuration... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 16 March 2016 at 17:17, Chris Barker <chris.barker@noaa.gov> wrote:
In theory, this makes sense to me. What it needs is someone to champion it. And address the inevitable questions/objections. The ones I immediately thought of were: 1. What if I want to install a version *not* for day to day use but just for testing (i.e., there needs to be an easily accessible "leave PATH alone" option). 2. How does this interact with uninstalls and upgrades? If I install 3.7, then 3.8 then uninstall 3.7, then install 3.6, then upgrade 3.8 to 3.8.1, what's left on PATH? (The answer I *want* is 3.8.1. That may well be a nightmare to implement). How does the above change if somewhere in the middle of that process I manually change PATH (in which case I may well *not* want 3.8.1 as the end result!) It's easy enough to dismiss point (2) as "well, you know what you're doing", but I have experience of people doing a series of installs like this, getting confused with PATH and doing a google search to find out how to "fix" it. So it is a genuine situation a non-expert user could find themselves in.
After all, what do people expect when they have MSWord version X, and then install MSWord version X+1
But nobody *ever* runs multiple versions of MS Word. Whereas there are genuine reasons for people (and not just experts, although admittedly not complete beginners) to run multiple versions of Python. The MS Word argument implies that the Python installer should automatically and silently uninstall any older versions of Python present on the user's machine. Paul
Paul Moore writes:
On 16 March 2016 at 17:17, Chris Barker <chris.barker@noaa.gov> wrote:
Really? To me, it never made a lot of sense even in theory. It's most likely to totally screw exactly the users it's addressed to (the ones who don't know how, don't wanna know how, and probably shouldn't be allowed[1], to manipulate PATH). It seems to me that the situation is 1. Power users and developers are often using a new Python in a "trial" situation or otherwise not wanting an *installed* Python on PATH. For historical reasons, they are used to solving that by not putting it on PATH by default. This weighed large in earlier discussions for the reasons you (Paul) give. As you also acknowledge, that large weight (vs. educators' needs) is hardly considered desirable by anybody, but the educator faction (often well-represented by folks like Raymond Hettinger and David Beazley) either didn't weigh in or didn't object or in the end conceded their objections were weak/had no good solution. 2. Python tries to provide both strong guarantees of backward compatibility without inhibiting development. This resulted in a kind of "punctuated equilibrium" evolution where x.y was theoretically backward-compatible with x.y-1, but that's never been quite true (bugs, *very* occasional changes of syntax as compared to the size of the language, errors that are caught and handled differently from the new version extension's definition, etc). Surprising users with *intermittent* and *hard to diagnose* bugs in other applications has never been considered acceptable, and the *nix distros I'm most familiar with (MacPorts, Debian, Gentoo) all provide a "python-select" utility for explicit choice of binding of "python", "python2", and "python3" to executables, with a user decision required to change the current bindings. This suggests to me that there are excellent reasons based in experience against defaulting to "upgrading" Python. "Sufficiently naive users" are just as vulnerable to such surprises, and as an educator myself, I would be unlikely to want to take responsibility for some other teacher's software being broken by my suggestion to upgrade Python so that *my* software can use newer syntax. I'd rather deal with my own problems by teaching students to deal with PATH (but see fn [2]). 3. In a previous geological epoch, naive beginner users used to be used to fixing up PATH, but that gave way in the early days of the current epoch to "computers for the rest of us (and big margins for Apple and Microsoft)" and "DLL hell", which by and large has been remedied by app-ization (ie, including all the DLLs you need, providing resources in a fixed hierarchy relative to the executable, and hard-coding those relative paths into the executable). This is how Microsoft and Apple arrange to ensure that only one instance of an app need to be installed, and resulted in such inelegant devices as "fat binaries" and the Microsoft Word format menu for saving. Unfortunately, this flat-out contradicts the Unix philosophy of modularized tools that do only one thing, and in the case of hosts involved in applications that face the Doomsday Machine usually called "the Internet", it's essential that certain services (crypto, authn, authz, ...) and important that others (anything with an overflowable buffer, which is everything) be upgraded in one place asap, rather than discarding the whole system in order to upgrade all apps that might be exposed. CPython chose to *not* distribute itself as app-ized by default, and in fact, doesn't do that at all, leaving it up to 3rd parties. I don't really see how to do that, anyway, given the huge amount of useful software that expects a previously-installed Python. Anyway, AFAIK that corner of the ecosystem is actually well-populated (Active State, Anaconda, etc). Why isn't one of those the appropriate solution to this problem for educators?[2]
After all, what do people expect when they have MSWord version X, and then install MSWord version X+1
But nobody *ever* runs multiple versions of MS Word.
Slightly off the mark, I think. The reason analogies to Word or Excel implode is that they suck as general-purpose programming environments (IMHO) and so rarely depend on third-party modules.[3] People write programs "strictly from need" (they're actually manipulating Word files), or because it's the only hammer they've got (accountants writing financial models in Excel), or backward-compatibility with programs written by one-hammer developers (financial models in Excel). And the language-level backward-compatibility burden is entirely borne by Microsoft -- which they are quite good at AFAICT, and that (expensive!) backward-compatibility is why "nobody [aka "Andrew Barnert"<wink/>] *ever*[sic] runs multiple versions of Word." Footnotes: [1] http://linux-mafia.com/~rick/faq/crybaby.html#allowed [2] Personally, the great majority of my students use Macs and at least on Macs the PSF-installed IDLE provides a nice icon in Applications, and that's how they get started, and even those who fall into the "shouldn't be allowed" group have little trouble handling Python 2 and Python 3 on the same box. So I don't even bother with those, although I'm currently reviewing Anaconda as a better solution for statistical applications. [3] Counter-examples welcome, I recognize my limited experience here.
On 17 March 2016 at 08:10, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Hmm, I think I follow what you're getting at. It does seem reasonable to me that if a user installs (a version of) Python, then they should find that the "python" command works and executes that version. Particularly so now that a default install of Python 3.5 on Windows puts the executables in a relatively hard to locate directory (so manually adding to PATH is tedious). Replace the "python" command with "py" in this statement and we have the current behaviour of the Python installer. I'm OK with conceding that anyone installing a second version of Python counts as an "advanced" user and should manage the results themselves :-) (Exception: if you uninstall your current version first, you're back to the "new install" case). So for new users (without Python install): "Install your preferred copy of Python, and use the command py to run Python (either to run a script, or for interactive use)". Everyone else should be prepared to accept a (brief) explanation on how to manage multiple versions of software on their computer. That seems reasonable to me, but I'm not an educator (at least, I only teach Python to IT professionals). I'm also inclined to assume that for the *really* "new to IT" users, Idle (which is available as a start menu item) is a better starting point anyway. But as I've already said, I'd rather leave the actual proposals to people with experience teaching new users. I offer the above simply as a perspective on how people with too much knowledge to empathise with complete newcomers might see the arguments :-) Paul
On 17 March 2016 at 09:14, Paul Moore <p.f.moore@gmail.com> wrote:
Great! I'm glad that we're agreed on the basic point that: Python is installed in standard way implies -> "python" command works in all the usual places
What? I thought we just agreed it should be "python"! :) This brings us full circle back to the reason I interjected in this thread: why are we making the standard invocation of Python different on Windows? I'll drag up a bit of conversation from earlier: On 15 March 2016 at 04:47, Nick Coghlan <ncoghlan@gmail.com> wrote:
(and it's also "python" on every other non-Windows OS I've used, leaving aside "python3") So are we agreed or not that "python" is the way to run... Python?
My own students are introduced via Idle and have no problem (on Windows or OSX) locating Idle graphically. It's later on when we expect them to use the command line they discover that they have PATH problems. But this is happening at the first point that they use the terminal (it seems natural since they've learned Python already that it should be one of the first terminal commands they would use). The installer already has the capability and a tickbox for this. See here: https://docs.python.org/3.5/using/windows.html The tickbox that says: "Install launcher for all users (recommended)" is ticked already and describes itself as being "recommended". The one that says "Add Python 3.5 to PATH" is unticked and apparently not "recommended". If we're agreed that the "python" command should work once Python is installed then why are we not "recommending" that people tick the box that does this? Advanced users should understand what this means and can decide for themselves whether or not they want to tick/untick this box so I don't see why they're relevant on the issue of what is default and what is recommended. Novices won't understand what the text means so we really need to think about them when choosing a default behaviour here. How about a UI that shows the user what Pythons are installed and allows them to select which one is on PATH? Another option would be to add a path configuration menu to Idle. This way a user can open Idle, go to something like settings->PATH configuration and then be presented with a list of installed Pythons and the ability to select which should be on PATH. That would be better than asking novices to go edit PATH but it still begs the question: if this is part of the standard setup then why is not standard to do it when installing? -- Oscar
On 17 March 2016 at 10:48, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Because for me, personally, I don't view cross-platform compatibility of "the command you use to invoke Python" as a goal. At least not until it's possible on Unix for "python" to invoke Python 3. I will happily concede that your goals are different. Paul
On Mar 17, 2016, at 01:10, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I wasn't running Word 2003 and Word 2007 as VBA development platforms, or using them side by side because I wanted both.[1] That's just what the installer decided to do.[2] Most people don't notice this, because how many users launch Word from the command line or via Win-R?[3] Not to mention that most people don't keep upgrading the same Windows box continuously over Office's 4-year dev cycle;[4] they're either still running 2003, or they threw that laptop away long ago. At any rate, the point is that Word is a terrible example of "everybody expects side-by-side installs but the latest-installed version wins"--most people don't expect side-by-side installs, and when you do get them, the latest version installed doesn't win (and, even if it did, they wouldn't notice). That doesn't necessarily mean it would be the wrong decision for Python, just that the argument "everyone else does it" doesn't help, because it's not true. If we want to talk about language-level compatibility, Visual Studio might be a better example than Office. And, as mentioned earlier in the thread, Visual Studio solves this problem by putting a "switching script" on the PATH, which adds the selected copy's executables to the PATH when run (and by adding special start menu shortcuts to open a new command prompt with the PATH set up). So, CL.EXE doesn't come from the latest MSVS installed either. [1]: In fact, the only reason I needed Word 2007 in the first place was that i contracted for a company that insisted I have it, even though every document they sent me worked just fine in OpenOffice... [2]: This is just a guess, but I'd bet it's because the $100 Office Home Professional 2007 didn't include the same subset of apps as the $100 Office Personal Business 2003 it replaced, and they didn't want people complaining about the upgrade taking away their PowerPoint or Access or Publisher or whatever the way people complained during the 2000-2003 upgrade. You'd think they could solve that by just offering the same set of packages of apps under consistent names and price points so this never came up, and I'll bet every 4 years, the suite-integration dev team for Office thinks they've convinced management that's a good idea, and then 3 months before release they discover that marketing convinced PM otherwise, and they now have to deal with it. [3]: People _do_ launch it via Win search for "word" nowadays, but that uses Windows' clever search guessing and learning, not anything configurable by the installer or the user, unlike Win-R "winword". [4]: Or, if they do, either it's an IT-managed upgrade, or they're installing a pirated copy of the full Office suite (which probably has a custom installer?).
On Wed, Mar 16, 2016 at 10:32 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Isn't that what this conversation is doing? :-)
yes, there should be a "leave PATH alone" checkbox, that is unchecked by default. If you want to get really fancy, you could require a question be asked of the user if there is already a python there. I have no idea if it's had to do this in a regular installer.
wait, I'm confused -- if the last thing you do is upgrade to 3.8.1, then that will be in the PATH by default, but what if you: install 3.7, then install 3.8, then uninstall 3.8 -- would 3.7 be left on the PATH? That could be pretty darn tricky -- though, again, if you undestand PATH manipulations, you can fix it, and if you don't you can go back and re-install 3.7, just to get the PATH set. It's easy enough to dismiss point (2) as "well, you know what you're
yup but if their google search turns up: "either hand-manipulate the PATH to fix this, or simply re-install the one you want" then we're in fine shape. It's not rare for "re-install the software" to be the easiest solution to messed up configuration.
no -- but it wouldn't be so bad if it did *appear* to have done that. The naive user will not be surprised -- it's common behavior -- and just reinstall the old one, even if all it does is re-set the PATH. The more sophisticated user will know to go in and mess with PATH. In short, if we overly simplistically break the world down inot people that "get" PATH, and those that don't: The default jsut click through witout reading it intstall should do the most expected thing for don't-get-PATH folks -- i.e. they get access to the mosst recent version installed. It should be possible for do-get-PATH folks to customize the system (ideally without having to get the registry, too!) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 18 March 2016 at 20:35, Chris Barker <chris.barker@noaa.gov> wrote:
Not really. By "champion" I mean "take the lead" - i.e., pull together all the arguments, summarise them, produce a proposal, write a patch (or get someone else to write it) create the tracker item, get a core dev to support it and shepherd it through to being committed. At the moment, all we're doing is discussing possibilities, nobody's stepped up to take the lead. I get the feeling that some participants in the discussion might think that discussion is enough, but I've seen too many of these threads fizzle out because no-one is interested enough, or has enough time, to do the hard bits. I just wanted to be clear that I started this thread for a *different* proposal, which came to a conclusion that I plan (other commitments permitting) to get implemented. But I'm *not* sufficiently interested in this new proposal to take it forward, so someone else will need to step up at some point if the idea is to go anywhere. Paul
On 16/03/2016 17:17, Chris Barker wrote:
Then grab a third party tool that does the same job. I use the Rapid Environment Editor http://www.rapidee.com/en/about but I understand that there are others. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 15 March 2016 at 21:25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Yeah, it's unfortunately currently still off by default. Since it's sysadmins that don't like it being on by default, and they're better equipped to change it back than Windows users being introduced to the command line for the first time, I'd prefer to see that particular default flipped to be opt-out rather than opt-in. Educators are the folks best positioned to argue for that change, since you're the ones that have to deal with the fallout of beginners installing Python by clicking through the installer prompts without realising they need to request the automatic PATH modification.
The major & minor versioned executables exist on *nix if people want to use them, but tend to make scripts and instructions more platform specific than they need to be. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 8 March 2016 at 11:22, Victor Stinner <victor.stinner@gmail.com> wrote:
I don't know. Personally, I don't like the versioned executables (will we get a py4, py5,...?) but that's just a personal preference. I believe that with an unversioned executable it should use the latest version by default, and the point of my email is that I think we're now at a point where special casing Python 2 is unreasonable, particularly on Windows where there is no tradition of a "system Python" which needs to be Python 2. If someone *else* wants to propose replacing py.exe with py2.exe and py3.exe then they can do that (and I'll be -1 on that proposal). You don't mention the fact that an unadorned "python" command on Unix typically invokes Python 2. As far as I know the only reason that was needed was because system Python scripts were written that way, back before Python 3 was around, and couldn't be updated to be Python 3 compatible. That reason doesn't apply on Windows. And on Windows, "python" has always referred to the currently active version of Python, whether 2 or 3. tl; dr; I'm against making the unversioned name "python" (or "py") forever mean Python 2. There are justifications for it on Unix, but none of those apply on Windows. Paul
On Wed, Mar 9, 2016 at 12:17 AM, Paul Moore <p.f.moore@gmail.com> wrote:
https://www.python.org/dev/peps/pep-0394/#exclusion-of-ms-windows On Unix, yes, but not on Windows. +1 for making py.exe now default to Python 3. ChrisA
On 03/08/2016 01:11 PM, Alexander Walters wrote:
Which is still asking for a change from what happens now; i.e. if 3.3 is installed first, then 2.7, py.exe will default to 2.7. I agree whichever is first installed should be default; I also think installer should have an option to change the py.exe default to the version being installed. -- ~Ethan~
On 08Mar2016 1334, Alexander Walters wrote:
"First installed" is a very difficult proposition, especially if you want versions of Python pre-3.6 to participate. "Last installed" is slightly better, though not easy to do without triggering systems that detect corrupted installations. Personally I think "latest version" is the best default (compared to the current "latest 2.x version"), so I'm +1 on removing the assumption that "PY_PYTHON" is "2" by default. Users can change their own default with any of the mechanisms described at https://docs.python.org/3/using/windows.html#customization Cheers, Steve
On 8 March 2016 at 22:00, Steve Dower <steve.dower@python.org> wrote:
Also, any dependency on installation order gets *very* messy if someone installs and uninstalls various versions. What does the default become if I uninstall the version that was previously the first (or last) installed? Would we need to keep details of precisely when everything was installed?
Latest version has the additional advantage of being essentially the current behaviour, just with the special case of "but prefer Python 2 over Python 3 if both are present" removed. (Note that technically the current rule is not simply "latest 2.x version", as if the user only has Python 3 installed, the latest 3.x version is used). The only other option I can think of is "use the one the user selected as the default Python (i.e., introspect the association for ".py" files) but even then we need a default default (!) for people who don't select any default Python. It's also messy to implement. And it's a bigger change from current behaviour.
Users can change their own default with any of the mechanisms described at https://docs.python.org/3/using/windows.html#customization
Absolutely. This should *only* apply when there is no user customisation - and it needs no further configurability, because the current methods are perfectly sufficient. Paul
How about the better option: No default preset default.. Make the user pick every time it's installed. Or the best option of them all: call Python 3... python3.exe and the shell launcher py3.exe. Or stop it with the launcher. I cannot think of many situations where a non-technical user would install the base python, and run modules. Most user applications ship their own interpreter. In enterprise situations, you would want WAY more control of what python you are using than py.exe offers. So who is py.exe for? So i am changing my -1 from changing the default behavior to -1 for its continued existence. On 3/8/2016 17:18, Paul Moore wrote:
On Wed, Mar 9, 2016 at 2:59 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Have a read of PEP 397 if you want to know why the launcher exists. https://www.python.org/dev/peps/pep-0397/ ChrisA
It modifies the windows registry to set a file association, which is a pain when you want double clicking a python file to open a text editor. So you have to change file associations, which was made really painful in recent versions of windows. On 3/8/2016 23:19, Ethan Furman wrote:
On Tue, Mar 8, 2016 at 11:06 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Linux users are used to being able to type "./script.py" on the command line and have the shebang tell the OS which version of Python to use. Windows doesn't support that because it instead works off of associating the file extension globally with an individual program, so ".py" can only be associated with a single executable, which is unworkable if you have both python2 and python3 scripts. py.exe solves that problem. So unless you have an alternative solution to enable Unix-like script launching with multiple Python versions from the command line, proposing to eliminate py.exe is a non-starter, at least with me. On Tue, Mar 8, 2016 at 11:22 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
So add an option to the installer to not set that file association. It's been a while since I installed a Python on my Windows machine, but IIRC that option may already be there (I could be mistaken, though).
On Tue, Mar 08, 2016 at 11:32:34PM -0500, Alexander Walters wrote:
Windows is not *nix. Supporting *nix idioms should not be a priority.
Python is over two decades old and we're up to version 3.5. You can hardly call this "a priority". It's been a long time coming. Besides, it surely depends on whether or not the idiom in question is valuable. Windows, and DOS before it, has copied many idioms from Unix over the years, as Unix/Linux have copied from Windows. For better or worse.
Then you should submit a bug or enhancement request to have that fixed. -- Steve
On Tue, Mar 08, 2016 at 11:22:19PM -0500, Alexander Walters complained about py.exe:
Sounds like your real beef is with Windows, not py.exe. As a programmer, couldn't you script something to change the file association and make it easier? When the pain of doing something gets greater than the pain of writing a short script, that's what I do. If you're having this problem, perhaps others are too, and the installer could make the file association change optional? -- Steve
On 9 March 2016 at 14:06, Alexander Walters <tritium-list@sdamon.com> wrote:
Volunteers don't generally donate their time to solve problems they don't have (and employers don't typically donate their employees' time to solve problems they or their customers don't have), which means "I don't personally have that problem, so I deny its very existence" is almost never a compelling line of argument in a community-driven open source project. In this case, we needed a cross-platform way for Python 3 scripts to indicate they were Python 3 only, and Python 2 scripts to indicate they were Python 2 only. *nix already had a way to indicate that via shebang lines, so it was natural to make that existing solution also work on Windows, rather than inventing something Windows specific (which would rather defeat the "cross-platform" objective). The fact that the chosen implementation strategy also made the "py" launcher usable at the command line was more of a side effect than the primary purpose of the exercise. In that regard, I think the meaning of "Make py.exe default to Python 3" as proposed in this thread needs to be spelled out more explicitly. If the proposal is to change the default behaviour for: * launching the interactive interpreter * running scripts without a shebang line * running scripts with an unrecognised shebang line then I think it's reasonable to switch all those to default to the newest CPython runtime on the machine, regardless of whether that's Python 2 or Python 3. However, if the proposal is also to change the handling of the following shebang lines: * #!/usr/bin/python * #!/usr/local/bin/python * #!/usr/bin/env python * #!python then I think those should continue to be handled in a manner consistent with PEP 394 (and as PEP 397 currently specifies): as referring to Python 2 (unless PY_PYTHON explicitly says otherwise or only Python 3 is available). Independently of the main topic of the thread, it does sound to me like there may be a valid enhancement request for the Windows installer to add a "Repair" mode that allows some of these settings (like adding or removing the file association) to be changed post-installation. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Mar 9, 2016 at 4:32 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Agree with both of these points. AIUI the original proposal was solely about the first half, with no recommendation of change to the second. What does py.exe do with a "#!/usr/bin/python" if the only Python installed is 3.5? Does it run it under 3.5, or error out? ChrisA
On 9 March 2016 at 05:39, Chris Angelico <rosuav@gmail.com> wrote:
My original post was prompted by interactive use, so I hadn't thought of the #!/usr/bin/python case. I can see Nick's point here. But...
What does py.exe do with a "#!/usr/bin/python" if the only Python installed is 3.5? Does it run it under 3.5, or error out?
I believe it runs Python 3. I no longer have a system with just Python 3 on, so I can't quickly test this, but I'd be surprised if it failed, based on my experience. And Nick noted that using Python 3 if it's the only one available is what the PEP says. So with regard to changing the behaviour of shebang lines I see the following points: 1. Compatibility with Unix, where an unadorned "python" in a shebang means "python 2". I personally hate this behaviour, and view it as a nasty wart of Unix. So I'm not in favour of promoting it on Windows (IMO, if you're writing scripts for publication, be explicit about whether you want Python 2 or 3 - an unqualified "python" in a shebang line should be only for cases of "I don't care, my code works for both" or purely personal code). But compatibility. 2. From what I recall of the py.exe code, implementing the exception only for shebang lines would be more complex than the current code, so I'd prefer there to be a demonstrated benefit. Unfortunately, it's really hard to know how much the feature is used. I only use it myself for personal scripts (and not much even then, tbh, because Powershell is weird with file associations). 3. On Python 3 only systems, the current behaviour isn't consistent with Unix anyway. I don't disagree with limiting the change to not affect unversioned shebang lines, but I'm not sure how much effort I'd personally be willing to put into special-casing that. We can see on that one when I start to look at the actual code, I guess... Paul
On Wed, Mar 9, 2016 at 3:47 AM, Paul Moore <p.f.moore@gmail.com> wrote:
I agree with Nick that Python 2 compatibility should be maintained for virtual paths in shebangs. I think a straight-forward solution is for locate_python() to gain a "virtual_mode" BOOL parameter, which is TRUE only when processing a virtual shebang, i.e. when called from maybe_handle_shebang(). For example, when wanted_ver is empty, locate_python would search the following sequence: configured_value = get_configured_value(config_key); if (configured_value) result = find_python_by_version(configured_value); if (result == NULL) result = find_python_by_version(virtual_mode ? L"2" : L"3"); if (result == NULL) result = find_python_by_version(virtual_mode ? L"3" : L"2"); This change works for me with various combinations of enabled PythonCore registry keys, PY_PYTHON values, and shebang lines. Note that the behavior of the plain "#!python" virtual shebang gets lumped in with virtual Unix paths, but I don't know why anyone would add this shebang without a target version.
On 9 March 2016 at 12:49, eryk sun <eryksun@gmail.com> wrote:
Thanks for reviewing the code for me - that does indeed look perfectly straightforward so I'm OK with following Nick's suggestion here. As there's not been much in the way of resistance to the proposal, do people think it requires a PEP? I plan on letting this thread run its course either way, it's just a matter of whether the next step should be a tracker item or a PEP. Thanks, Paul
On 09/03/2016 13:21, Paul Moore wrote:
I do not believe that this needs a PEP, a tracker item should be fine IMHO. We should just ensure that the original authors of the PEP are aware, as missing out their opinions would be a disservice to the Python Windows community, as small as that may be when compared to *nix. Just my £0.02p worth. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Thu, Mar 10, 2016 at 8:20 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Given that this is basically a Windows-only change, it doesn't matter how large or small the Windows community is - they're the people who primarily matter :) If someone proposed a change to the way things are done on OS/2, it'd be worth getting the opinions of both of the Python OS/2 users... :P ChrisA
On 9 March 2016 at 21:25, Chris Angelico <rosuav@gmail.com> wrote:
Although it is a change to Windows-only I think it is important to think about the consistency between the way that this works on Windows compared with other operating systems. Inconsistencies here can be awkward for novices. Allow me to spell out my scenario... I teach a couple of University programming units in which students learn to program in Python, C and Java. The cohort for these units this year was 160 students. I often find myself giving the students instructions such as you can run this script I've given you with $ python myscript.py Now imagine that you've given that instruction to 160 students mostly using Windows and OSX (and a few Linux users). I find it very annoying that this could invoke Python 2 or 3 depending on the OS etc that the students are using. py.exe should solve this since I can write py -3 and then (I assume) it would lead to an error if no Python 3 version is available. However that doesn't work on OSX or Linux. Okay so maybe we should just use the shebangs. I can explain to all my students what shebangs are and instruct the OSX students to set the executable bit. Then I can say so just run $ ./myscript.py however on Windows this uses file associations which is flaky. In the past I've seen bugs where e.g. input/output redirection didn't work for scripts run in this way. It also may not work in myriad other contexts where a command line may be used. One example is from Makefiles. So when my students are working in C I can give them a Python script that will test the output of their C program and I can tell them to add this to their Makefile e.g.: test: myprog.exe ./myscript.py At this point (on Windows) various failures are possible. If make simply calls CreateProcess it fails since myscript.py isn't an exe file (I believe it also accepts .bat files but does not observe file associations). If make inspects the shebang it may come to a very different conclusion from the one that py.exe would have (e.g. that python3 does not exist since it is not on PATH). Over time I've seen this go wrong in a number of ways and have ultimately concluded that anything involving using file associations is fragile. Personally I would really like it if we could have improved consistency across OSes when it comes to invoking Python. So I would really like it if we can either have py (and maybe py3) *everywhere* or if that's not possible find some solution that does work everywhere. Can we have a single command line that guarantees to run Python 3 (or error out)? -- Oscar
On Mar 12, 2016, at 15:38, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
What if Python 3 created a symlink (or, for non-NTFS drives, a copy) of Python.exe named Python3.exe? Would that be sufficient for you to just tell your students to run: $ python3 myscript.py At any rate, this seems to be a separate issue from the one this thread is about. It's already true that py.exe is Windows-specific; no change to what it does is going to make the same command lines work on Windows and *nix. Only some new proposal (add a py command for Unix, add python2 and python3 links for Windows, make Python.exe itself a dispatcher as Apple's /usr/bin/python is on Mac, ...) is going to help you. So you might be better off creating a new thread instead of adding on to one that's mostly been resolved and a lot of people have stopped reading.
On 13 March 2016 at 04:09, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
At any rate, this seems to be a separate issue from the one this thread is about. It's already true that py.exe is Windows-specific; no change to what it does is going to make the same command lines work on Windows and *nix. Only some new proposal (add a py command for Unix, add python2 and python3 links for Windows, make Python.exe itself a dispatcher as Apple's /usr/bin/python is on Mac, ...) is going to help you. So you might be better off creating a new thread instead of adding on to one that's mostly been resolved and a lot of people have stopped reading.
Agreed. Just to summarise the final state of this thread, the consensus seems to be: 1. For interactive use, make py.exe launch the latest version installed on the machine, without special-casing a preference for Python 2. 2. For shebang lines where an unversioned name is used, retain the current behaviour (for compatibility with Unix). 3. When the user explicitly chooses a version, or has configured the launcher via the ini file or environment variables, no change to current behaviour. 4. The change is small enough that it doesn't need a PEP. On that basis, I'll make some time to brush off my C skills and raise a tracker item, targeted at Python 3.6. As far as I know, there's no special exemption for new features in the launcher being backported to older versions of Python, and there's no "standalone" launcher installer, so this change will only affect people who install the launcher via the Python 3.6 or later installer. Paul
The past and future of Python (a little off topic, sorry :): Python 2: $ python myapp.py Python 3: $ py myapp.py Python 4: $ p myapp.py Python 5: $ myapp Python 6: Executing Python applications will be natively built into every OS, and the problem of a cross-platform way to conveniently distribute and run a Python *application* will be magically solved. - Koos
On 13 March 2016 at 11:39, Paul Moore <p.f.moore@gmail.com> wrote:
I guess it's maybe just because this thread has made me realise that py.exe has changed purpose with respect to what it seemed (to me) to be before. When I was using Windows I used to always arrange for python and python3 to be available on PATH and I only used the "py" command as a way of explicitly selecting a particular non-default Python version. The idea that the default for py.exe needs to be python 3 suggests that people are now using "py" as the primary command line invocation of Python on Windows. I think is unfortunate as it takes Windows off in a different direction from every other OS. That intention wasn't the impression I had of PEP 397 at the time. -- Oscar
On 14 March 2016 at 17:18, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Indeed, it wasn't, and I would have always said that people should put the version of Python that they want on PATH. Indeed, I still do that. I don't think there's any "official" change in policy, nor is there a groundswell of people using py.exe to invoke Python on the command line. But PATH management remains messy and is probably even more so now that per-user installs are the default (per-user PATH entries go after system PATH entries on Windows, which makes the default behaviour complex to describe, there's no way around that). So using py.exe (which is always on PATH, and which gives access to any Python) is possibly a more attractive option nowadays. I've personally been experimenting with using it, and I've found that the "Python 2 takes priority" behaviour is suboptimal for my interactive use - this thread implies that I'm not alone in that. So I'll be following up with a change to improve that default. That's all, as far as I'm concerned. But as for "the canonical way to run Python" - much less "the canonical way to ensure you're running Python 3 (or 2)" - I don't think there's any such thing, and honestly there never has been since Python 3 came into existence and a proportion of the community needed "python" to continue referring to Python 2, even though a newer version had been released. If you (or anyone else) wanted to put together a proposal for such a cross-platform standard way of launching specific Python versions, then by all means go ahead. I can imagine it would be immensely useful to have such a thing in a teaching context. Personally it would be of no value to me, though, so I'm not going to be interested in such a proposal. I apologise if I gave the impression in this thread that there's any sort of "official" change in advice on how to launch Python. As far as I know, there hasn't been. Paul
On 15 March 2016 at 09:01, Paul Moore <p.f.moore@gmail.com> wrote:
It's still "python" - that works regardless of version on Windows (with a suitably configured PATH), in virtual environments and in pyenv and conda environments (and probably in Enthought Canopy as well, but I haven't checked that). The only places where it doesn't work are: * Windows without a properly configured PATH (and without a tool like vex or conda) * accessing Python 3 on *nix systems (without a tool like vex, pyenv or conda) On the *nix side of things, the long term objective is to get "python" to a point of being usable for the latter case, but there's still a lot of other things to be done before that's a realistic option (e.g. migrating system packages over to using their own dedicated binary or symlink, so "python" can be switched to point to something else without affecting system services). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 15 March 2016 at 04:47, Nick Coghlan <ncoghlan@gmail.com> wrote:
You don't need to apologise in any case but that's not what I meant. Also I'm not disagreeing with your proposal to change the default behaviour of py.exe. It's not so much "official policy" that I was lamenting but just the way things have evolved. I don't think that anyone really intended to reach the current situation where the different OSes have diverged and there's no longer a clear uniform command line to run a Python script.
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).
Well that would initially improve things but what happens when python 4 comes around? Really I think that for something like this having major-versioned executables is a good idea. It's just a shame that it wasn't done consistently. -- Oscar
On Mar 15, 2016, at 04:25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Nothing. It'll be called just "python" on both platforms. Just like when Python 2.0 came out, it was just called "python", not "python2", and was no more incompatible with 1.5 than 1.5 had been with 1.4. Python 3 was a once-in-a-lifetime, or at least once-in-a-generation, thing, not a plan to overhaul everything once/decade. (At least that's the impression I get from the PEPs, Guido's blogs, other dev's blogs, and the mailing lists.) The only way I can imagine Python 4.0 being incompatible is 3.9 is followed by 3.10 and somewhere in the distant future the memory of the 2.5->3.0 transition has faded (or the *nix environment has changed) to the point where a similar 3.14->4.0 seems like a good idea.
On 15 March 2016 at 11:25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
I would have thought that is relatively easy to resolve. A pain to have to do in a classroom environment, certainly, but manageable. 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. 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. On Unix, tell people just "run python3". Having versioned executables available on Windows might be helpful, but only a little bit as they still wouldn't be on PATH. Paul
On 15 March 2016 at 12:01, Paul Moore <p.f.moore@gmail.com> wrote:
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.
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.
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. -- Oscar
On 15 March 2016 at 12:38, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Why would we not want python on PATH?
You should probably go and hunt out previous discussions (your best bet is likely the python-dev archives). They were pretty extensive, and I'd likely get details wrong if I tried to summarise.
Certainly it's only an issue if the user has multiple Pythons. Of course, this can include things like conda or ActiveState Python, or programs like Lilypond that bundle Python. Some issues I recall: 1. You can improve the Python 3.6 installer, but if the user installs Python 2.7 after 3.6, they'll get the old installer with that. And conda may do something else altogether. So fixing just one installer doesn't remove the issue. 2. User installs can only add to the user part of PATH, which the OS adds *after* the system PATH. So if you do a system install and a user install, the system install will *always* take precendence, regardless of what you ask for. This is particularly problematic as Python 3.5+ defaults to a user install. 3. When you ask for a new Python to be added to PATH, should previous ones be removed? If you then uninstall the new Python, will you be left with nothing on PATH? I've seen the view expressed that PATH is for the user to manage and installers have no business changing it at all. While I'm not sure that many people who write installers would agree with that, having dealt with my own share of messed up PATHs caused by installers, I can certainly sympathise with that position. Paul
Le 15/03/2016 14:12, Paul Moore a écrit :
Yes, but you are able to deal with those issues. And they happen rarely. Failing to run Python in the terminal occurs every single introduction course I give. Every single one. And without help, a beginner will have trouble solving it because it's hard to search in Google for something you know nothing about. So some of them, the ones that can understand English and see the value of looking it up for hours, may solve it. The other ones will give up. Another problem is the gigantic time and energy wasted for this : I have to tell about this box in every course, write it down (with screenshot) in every tutorials, mention it in every videos I do. And yet, yet! People still come to me, write comments, emails, not understanding why typing "python" in this big black windows doesn't work. And then, you have the worst case scenario. The one where the person, a bit tech saavy, tried to edit the PATH manually in this tiny, unresizeable window, and messed it up. Now, try to diagnose that over skype, or on a forum, or on twitter... I already made the choice to spends hours of my life helping people with Python, but I wish I could spend it on explaining how they can make their computer do nice stuff, not on making sure they tick boxes.
On 15 March 2016 at 16:50, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
Yes, but you are able to deal with those issues. And they happen rarely.
Agreed. One of the issues with the debates about whether to add Python to PATH by default was that the people involved - the Python core devs - were not at all typical users (they probably have multiple Python versions installed, and they are comfortable with technical details like PATH management, etc). As Nick said, we need people like educators, with real experience of what the stumbling blocks for new users are, to provide a more realistic justification for the change. Maybe someone in this discussion could raise a feature request on bugs.python.org suggesting this gets changed? Paul
On Tue, Mar 15, 2016, at 13:47, Paul Moore wrote:
I think what might be most appropriate would be to have a "Python Console" in the start menu (alongside the IDLE entry) which sources a bat file to add the correct python version (and the scripts directory for pip and easy_install) to that window's PATH, rather than installing it in the global PATH, and users can learn to start the console from that icon when they want to run python commands. Inspired by the fact that e.g. Visual Studio has something that does the same.
On 15Mar2016 1231, Random832 wrote:
This is one of two solutions I'd be comfortable with. The other is to rename "py[w].exe" as "python[w].exe". PATH is used to resolve system DLLs and common commands. Over time, better security features are being added for core system components, but it is still possible to hijack programs this way. It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change. In my experience, it's mostly Python 3.x turning into 2.7 because a keen Python developer meets a jaded one and gets told they should only be using old things... Windows Installer does not have a nice mechanism to handle ordering of PATH entries or detecting existing ones, unless all the installers are cooperating. It certainly doesn't handle any case here where users may add/remove Python installs whenever they like. This is why the launcher was created. I have always been -1 on modifying PATH by default, and trading an early problem for a later, more subtle, problem does not convince me. And I say this as someone who has taught classes of undergraduate students how to use Python on Windows, and had to deal with the same problems. I'm not trying to lord it over the installer just because I'm the one who wrote and maintains it - if someone else files a patch and one of the other committers puts it in, so be it. But I'd much rather (a) make users choose up front to have an environment where "python.exe" is easily accessible, or (b) make "python.exe" consistently launch the right version. Cheers, Steve
On 15 March 2016 at 20:58, Steve Dower <steve.dower@python.org> wrote:
I'm very conscious that as an experienced user, I don't actually care what the installer does, as I'll reconfigure things the way I want anyway. However, in my opinion, the worst part of having a "Python command prompt" start menu item is that it assumes everyone wants to use cmd.exe. But there's also powershell users to consider. Furthermore, having a command prompt that does what you want doesn't help people who want to run Python from something like a scheduled task. Of course, for Python it's no issue, as you can use the full path to the interpreter and that's fine - I learned my dislike of this technique from Visual Studio, where it's not that simple... I'm not sure renaming py.exe as python.exe is such a good idea either. I don't have a strong reason to give, just a suspicion that the subtly different arguments, and the fact that it (by design) doesn't respect PATH, make me concerned that it'll cause even more subtle issues than the current approach. Also, it's not possible for users with their own approaches to "opt out", where a PATH setting can be altered by the user. Anyway, as I say, I'll probably stick to doing things my own way whatever happens. Paul
On Tue, Mar 15, 2016 at 3:58 PM, Steve Dower <steve.dower@python.org> wrote:
I've wondered about allowing the launcher to determine the Python it should invoke by its own name. That is, if the launcher is named 'python3.exe' it should behave as 'py -3'; 'python2.7.exe' should behave as 'py -2.7'. I wrote a patch to that effect a year or two ago but never got it polished up enough to submit. What about doing this, and at launcher install time (or at 'repair installation' time) create links for each found Python (and python2/python3 if they exist)? -- Zach
On 15Mar2016 1414, Zachary Ware wrote:
Very tough to automatically install for all found Pythons like this through an MSI, but if the not-found exit code is 9009 then there's no reason we can't just install copies for as many versions as we like. What would also be nice is "activatepyX.Y" scripts (presumably in both .cmd and .ps1 formats) that would modify the current PATH. I started a PEP a while back proposing these but never finished. If we start adding this many files I'd also want to move the launchers into their own directory (probably "C:\Program Files\Common Files\Python\Launcher") and add that to the global PATH. As long as we strictly control what files are in there, I have no problem with adding it - we just don't want any random DLL or EXE getting in there. Cheers, Steve
On Mar 15, 2016, at 13:58, Steve Dower <steve.dower@python.org> wrote:
But isn't the whole point here that we want novices to be able to treat python and/or python3 as a "common command", just like py? That implies either putting the executable in an existing PATH directory, or adding the executable's directory to the PATH (or, of course, renaming py, as you suggest, since that already gets put into an existing directory).
It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change.
If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow or whatever and get a quick answer. And that means we don't have to solve the conflict problems, the uninstall leave-behind problems, etc. for multiple pythons.
On Wed, Mar 16, 2016 at 8:29 AM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:
please no -- it should be easy and obvious to "upgrade" python -- i.e. the last one you installed is what "just works". If the default does that, then a non-defautl option to not override the existing one would be nice: """ Warning: there is an existing python installed on this system: check here if you want to continue to have the old version be used as the default. Leve the box unchecked if you want the version to be the new default. """ or something like that. After all, what do people expect when they have MSWord version X, and then install MSWord version X+1 ? They expect that when they run Word after that, they'll get the new version. Is this going to surprise anyone??? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Mar 16, 2016, at 10:22, Chris Barker <chris.barker@noaa.gov> wrote:
Last time I did that, I ended up with Office 2007 in a completely separate directory from Office 2003, with their own Start Menu folders. The one under "Office" was still 2003, but there was a new one under "Microsoft Office" that I had to find. And Win-F "winword" still ran 2003. And .doc files were still owned by 2003 (but docx by 2007). And all of my system templates and most of my addons from 2003 weren't available in 2007 until I manually reinstalled them for it. And so on. I don't think anyone expects that with Office. There are other kinds of apps where people _do_ expect it. For example, if you have TuneUp 2.4.3 and then install TuneUp 2.5.7, when you run a TuneUp (whether via the Start menu, or Win-F, or because you had the "auto-start with iTunes checkbox on, etc.), you'll definitely get 2.5.7. But that's because 2.4.3 no longer exists on your system. I don't think we want a Python 3.6 install to automatically uninstall or overwrite 2.7, or vice-versa. Which means it's like Office, not like TuneUp. Installing two Python versions on the same machine is always going to require some kind of management by the user.
The uninstall problem is actually that "python" would stop working completely in that case, and it's not necessarily obvious why or how to fix it. The leave-behind problem doesn't really matter as the directory is not searched if it doesn't exist, but we also don't leave behind entries added by the installer. A user who customizes their own PATH will obviously need to manually remove the entry, but that's a manual action both times so I don't see any concern there. At one point I was trying to convince the Windows team to add a global "python" command to all Windows installs (probably 10 and later - we don't backport stuff like this, but it could be a manual install) that would act like the py.exe launcher but also automatically download Python if you didn't have it. What would people think if I got that to happen? Top-posted from my Windows Phone -----Original Message----- From: "Andrew Barnert" <abarnert@yahoo.com> Sent: 3/16/2016 8:30 To: "Steve Dower" <steve.dower@python.org> Cc: "python-ideas@python.org" <python-ideas@python.org> Subject: Re: [Python-ideas] Make py.exe default to Python 3 On Mar 15, 2016, at 13:58, Steve Dower <steve.dower@python.org> wrote:
But isn't the whole point here that we want novices to be able to treat python and/or python3 as a "common command", just like py? That implies either putting the executable in an existing PATH directory, or adding the executable's directory to the PATH (or, of course, renaming py, as you suggest, since that already gets put into an existing directory).
It also has a serious conflict problem once the second version of Python is installed with this option enabled, in that *anything* currently referring to just "python" will change.
If this is only intended for rank beginners, what about just disabling the checkbox, with a warning, if there's already a program named "Python" anywhere on the PATH? Then, when someone gets into trouble because they're installing two Pythons, they'll get a warning and be able to ask their teacher or search StackOverflow or whatever and get a quick answer. And that means we don't have to solve the conflict problems, the uninstall leave-behind problems, etc. for multiple pythons.
On 16 March 2016 at 18:06, Ethan Furman <ethan@stoneleaf.us> wrote:
Agreed it would be awesome. I see no reason to bother with 2.x, though. If the user knows enough to know they want 2.x they can download and install it. Otherwise just give people the latest and greatest Python. Paul
Absolutely! I have the same experience in my classes. The reality is that MS has not updated the GUI for setting PATH since Windows 3.1 as far as I can tell. It sucks. So we really, really, want this to Just Work for newbies. Yes, things get complicated with multiple versions of Python, etc, but that is going to require understanding s fair bit about PATH et al. No matter how you slice it. Let's be sure the simple case is easy and obvious. -CHB
On Tue, Mar 15, 2016 at 9:59 PM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
The reality is that MS has not updated the GUI for setting PATH since Windows 3.1 as far as I can tell. It sucks.
Actually, Windows 10 (or at least Windows 10 with the latest updates) introduced a much, MUCH nicer interface for PATH editing. Here's a screenshot: http://snag.gy/WH4Oj.jpg With this interface, one can edit individual entries (an edit to the Python 2.7 \Scripts folder in the system PATH is in progress in this screenshot), use the browse button to select new folders via GUI, tweak the order of the list, easily remove entries, and so forth. The details of the plaintext version of PATH that one would use at the command prompt are hidden behind the "edit text" button. I recently performed a massive cleanup to my PATHs after discovered this new interface, and it was really easy.
Le 16/03/2016 03:10, Jonathan Goble a écrit :
I noticed that last month, and it's a good thing, but universities and companies are not going to upgrade for years (if they do it at all). Most of my students, when using windows, are using Windows 7. A few is running Vista or 8. Sometime, I meet some XP (yeah, I know). I only met one using Windows 10, and it was his own laptop. Plus fixing a way to fix a problem is, while improving the situation, probably not the best way to look at the situation.
Finally! and after only 20 years. Great to see that. But we will be dealing with pre Windows10 for a a good long time :-) Plus fixing a way to fix a problem is, while improving the situation,
probably not the best way to look at the situation.
well, it does change teh burden teh choice is between auto-setting PATH, and requiring people to set/adjust it themselves -- each has it's advantages. And how easy it is to adjsut it yourself does effect the trade-off. But as we will be supporting Windows pre-10 for a long time, we still need it to "just work" for less sophisticated users without them having to mess with PATH. As in: If someone installs a version of python with defaults, they should then get that version when they type "python" (or maybe "py") at the command line. If they want something other than the last one they installed, then they'll have to mess with PATH or other configuration... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 16 March 2016 at 17:17, Chris Barker <chris.barker@noaa.gov> wrote:
In theory, this makes sense to me. What it needs is someone to champion it. And address the inevitable questions/objections. The ones I immediately thought of were: 1. What if I want to install a version *not* for day to day use but just for testing (i.e., there needs to be an easily accessible "leave PATH alone" option). 2. How does this interact with uninstalls and upgrades? If I install 3.7, then 3.8 then uninstall 3.7, then install 3.6, then upgrade 3.8 to 3.8.1, what's left on PATH? (The answer I *want* is 3.8.1. That may well be a nightmare to implement). How does the above change if somewhere in the middle of that process I manually change PATH (in which case I may well *not* want 3.8.1 as the end result!) It's easy enough to dismiss point (2) as "well, you know what you're doing", but I have experience of people doing a series of installs like this, getting confused with PATH and doing a google search to find out how to "fix" it. So it is a genuine situation a non-expert user could find themselves in.
After all, what do people expect when they have MSWord version X, and then install MSWord version X+1
But nobody *ever* runs multiple versions of MS Word. Whereas there are genuine reasons for people (and not just experts, although admittedly not complete beginners) to run multiple versions of Python. The MS Word argument implies that the Python installer should automatically and silently uninstall any older versions of Python present on the user's machine. Paul
Paul Moore writes:
On 16 March 2016 at 17:17, Chris Barker <chris.barker@noaa.gov> wrote:
Really? To me, it never made a lot of sense even in theory. It's most likely to totally screw exactly the users it's addressed to (the ones who don't know how, don't wanna know how, and probably shouldn't be allowed[1], to manipulate PATH). It seems to me that the situation is 1. Power users and developers are often using a new Python in a "trial" situation or otherwise not wanting an *installed* Python on PATH. For historical reasons, they are used to solving that by not putting it on PATH by default. This weighed large in earlier discussions for the reasons you (Paul) give. As you also acknowledge, that large weight (vs. educators' needs) is hardly considered desirable by anybody, but the educator faction (often well-represented by folks like Raymond Hettinger and David Beazley) either didn't weigh in or didn't object or in the end conceded their objections were weak/had no good solution. 2. Python tries to provide both strong guarantees of backward compatibility without inhibiting development. This resulted in a kind of "punctuated equilibrium" evolution where x.y was theoretically backward-compatible with x.y-1, but that's never been quite true (bugs, *very* occasional changes of syntax as compared to the size of the language, errors that are caught and handled differently from the new version extension's definition, etc). Surprising users with *intermittent* and *hard to diagnose* bugs in other applications has never been considered acceptable, and the *nix distros I'm most familiar with (MacPorts, Debian, Gentoo) all provide a "python-select" utility for explicit choice of binding of "python", "python2", and "python3" to executables, with a user decision required to change the current bindings. This suggests to me that there are excellent reasons based in experience against defaulting to "upgrading" Python. "Sufficiently naive users" are just as vulnerable to such surprises, and as an educator myself, I would be unlikely to want to take responsibility for some other teacher's software being broken by my suggestion to upgrade Python so that *my* software can use newer syntax. I'd rather deal with my own problems by teaching students to deal with PATH (but see fn [2]). 3. In a previous geological epoch, naive beginner users used to be used to fixing up PATH, but that gave way in the early days of the current epoch to "computers for the rest of us (and big margins for Apple and Microsoft)" and "DLL hell", which by and large has been remedied by app-ization (ie, including all the DLLs you need, providing resources in a fixed hierarchy relative to the executable, and hard-coding those relative paths into the executable). This is how Microsoft and Apple arrange to ensure that only one instance of an app need to be installed, and resulted in such inelegant devices as "fat binaries" and the Microsoft Word format menu for saving. Unfortunately, this flat-out contradicts the Unix philosophy of modularized tools that do only one thing, and in the case of hosts involved in applications that face the Doomsday Machine usually called "the Internet", it's essential that certain services (crypto, authn, authz, ...) and important that others (anything with an overflowable buffer, which is everything) be upgraded in one place asap, rather than discarding the whole system in order to upgrade all apps that might be exposed. CPython chose to *not* distribute itself as app-ized by default, and in fact, doesn't do that at all, leaving it up to 3rd parties. I don't really see how to do that, anyway, given the huge amount of useful software that expects a previously-installed Python. Anyway, AFAIK that corner of the ecosystem is actually well-populated (Active State, Anaconda, etc). Why isn't one of those the appropriate solution to this problem for educators?[2]
After all, what do people expect when they have MSWord version X, and then install MSWord version X+1
But nobody *ever* runs multiple versions of MS Word.
Slightly off the mark, I think. The reason analogies to Word or Excel implode is that they suck as general-purpose programming environments (IMHO) and so rarely depend on third-party modules.[3] People write programs "strictly from need" (they're actually manipulating Word files), or because it's the only hammer they've got (accountants writing financial models in Excel), or backward-compatibility with programs written by one-hammer developers (financial models in Excel). And the language-level backward-compatibility burden is entirely borne by Microsoft -- which they are quite good at AFAICT, and that (expensive!) backward-compatibility is why "nobody [aka "Andrew Barnert"<wink/>] *ever*[sic] runs multiple versions of Word." Footnotes: [1] http://linux-mafia.com/~rick/faq/crybaby.html#allowed [2] Personally, the great majority of my students use Macs and at least on Macs the PSF-installed IDLE provides a nice icon in Applications, and that's how they get started, and even those who fall into the "shouldn't be allowed" group have little trouble handling Python 2 and Python 3 on the same box. So I don't even bother with those, although I'm currently reviewing Anaconda as a better solution for statistical applications. [3] Counter-examples welcome, I recognize my limited experience here.
On 17 March 2016 at 08:10, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Hmm, I think I follow what you're getting at. It does seem reasonable to me that if a user installs (a version of) Python, then they should find that the "python" command works and executes that version. Particularly so now that a default install of Python 3.5 on Windows puts the executables in a relatively hard to locate directory (so manually adding to PATH is tedious). Replace the "python" command with "py" in this statement and we have the current behaviour of the Python installer. I'm OK with conceding that anyone installing a second version of Python counts as an "advanced" user and should manage the results themselves :-) (Exception: if you uninstall your current version first, you're back to the "new install" case). So for new users (without Python install): "Install your preferred copy of Python, and use the command py to run Python (either to run a script, or for interactive use)". Everyone else should be prepared to accept a (brief) explanation on how to manage multiple versions of software on their computer. That seems reasonable to me, but I'm not an educator (at least, I only teach Python to IT professionals). I'm also inclined to assume that for the *really* "new to IT" users, Idle (which is available as a start menu item) is a better starting point anyway. But as I've already said, I'd rather leave the actual proposals to people with experience teaching new users. I offer the above simply as a perspective on how people with too much knowledge to empathise with complete newcomers might see the arguments :-) Paul
On 17 March 2016 at 09:14, Paul Moore <p.f.moore@gmail.com> wrote:
Great! I'm glad that we're agreed on the basic point that: Python is installed in standard way implies -> "python" command works in all the usual places
What? I thought we just agreed it should be "python"! :) This brings us full circle back to the reason I interjected in this thread: why are we making the standard invocation of Python different on Windows? I'll drag up a bit of conversation from earlier: On 15 March 2016 at 04:47, Nick Coghlan <ncoghlan@gmail.com> wrote:
(and it's also "python" on every other non-Windows OS I've used, leaving aside "python3") So are we agreed or not that "python" is the way to run... Python?
My own students are introduced via Idle and have no problem (on Windows or OSX) locating Idle graphically. It's later on when we expect them to use the command line they discover that they have PATH problems. But this is happening at the first point that they use the terminal (it seems natural since they've learned Python already that it should be one of the first terminal commands they would use). The installer already has the capability and a tickbox for this. See here: https://docs.python.org/3.5/using/windows.html The tickbox that says: "Install launcher for all users (recommended)" is ticked already and describes itself as being "recommended". The one that says "Add Python 3.5 to PATH" is unticked and apparently not "recommended". If we're agreed that the "python" command should work once Python is installed then why are we not "recommending" that people tick the box that does this? Advanced users should understand what this means and can decide for themselves whether or not they want to tick/untick this box so I don't see why they're relevant on the issue of what is default and what is recommended. Novices won't understand what the text means so we really need to think about them when choosing a default behaviour here. How about a UI that shows the user what Pythons are installed and allows them to select which one is on PATH? Another option would be to add a path configuration menu to Idle. This way a user can open Idle, go to something like settings->PATH configuration and then be presented with a list of installed Pythons and the ability to select which should be on PATH. That would be better than asking novices to go edit PATH but it still begs the question: if this is part of the standard setup then why is not standard to do it when installing? -- Oscar
On 17 March 2016 at 10:48, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Because for me, personally, I don't view cross-platform compatibility of "the command you use to invoke Python" as a goal. At least not until it's possible on Unix for "python" to invoke Python 3. I will happily concede that your goals are different. Paul
On Mar 17, 2016, at 01:10, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I wasn't running Word 2003 and Word 2007 as VBA development platforms, or using them side by side because I wanted both.[1] That's just what the installer decided to do.[2] Most people don't notice this, because how many users launch Word from the command line or via Win-R?[3] Not to mention that most people don't keep upgrading the same Windows box continuously over Office's 4-year dev cycle;[4] they're either still running 2003, or they threw that laptop away long ago. At any rate, the point is that Word is a terrible example of "everybody expects side-by-side installs but the latest-installed version wins"--most people don't expect side-by-side installs, and when you do get them, the latest version installed doesn't win (and, even if it did, they wouldn't notice). That doesn't necessarily mean it would be the wrong decision for Python, just that the argument "everyone else does it" doesn't help, because it's not true. If we want to talk about language-level compatibility, Visual Studio might be a better example than Office. And, as mentioned earlier in the thread, Visual Studio solves this problem by putting a "switching script" on the PATH, which adds the selected copy's executables to the PATH when run (and by adding special start menu shortcuts to open a new command prompt with the PATH set up). So, CL.EXE doesn't come from the latest MSVS installed either. [1]: In fact, the only reason I needed Word 2007 in the first place was that i contracted for a company that insisted I have it, even though every document they sent me worked just fine in OpenOffice... [2]: This is just a guess, but I'd bet it's because the $100 Office Home Professional 2007 didn't include the same subset of apps as the $100 Office Personal Business 2003 it replaced, and they didn't want people complaining about the upgrade taking away their PowerPoint or Access or Publisher or whatever the way people complained during the 2000-2003 upgrade. You'd think they could solve that by just offering the same set of packages of apps under consistent names and price points so this never came up, and I'll bet every 4 years, the suite-integration dev team for Office thinks they've convinced management that's a good idea, and then 3 months before release they discover that marketing convinced PM otherwise, and they now have to deal with it. [3]: People _do_ launch it via Win search for "word" nowadays, but that uses Windows' clever search guessing and learning, not anything configurable by the installer or the user, unlike Win-R "winword". [4]: Or, if they do, either it's an IT-managed upgrade, or they're installing a pirated copy of the full Office suite (which probably has a custom installer?).
On Wed, Mar 16, 2016 at 10:32 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Isn't that what this conversation is doing? :-)
yes, there should be a "leave PATH alone" checkbox, that is unchecked by default. If you want to get really fancy, you could require a question be asked of the user if there is already a python there. I have no idea if it's had to do this in a regular installer.
wait, I'm confused -- if the last thing you do is upgrade to 3.8.1, then that will be in the PATH by default, but what if you: install 3.7, then install 3.8, then uninstall 3.8 -- would 3.7 be left on the PATH? That could be pretty darn tricky -- though, again, if you undestand PATH manipulations, you can fix it, and if you don't you can go back and re-install 3.7, just to get the PATH set. It's easy enough to dismiss point (2) as "well, you know what you're
yup but if their google search turns up: "either hand-manipulate the PATH to fix this, or simply re-install the one you want" then we're in fine shape. It's not rare for "re-install the software" to be the easiest solution to messed up configuration.
no -- but it wouldn't be so bad if it did *appear* to have done that. The naive user will not be surprised -- it's common behavior -- and just reinstall the old one, even if all it does is re-set the PATH. The more sophisticated user will know to go in and mess with PATH. In short, if we overly simplistically break the world down inot people that "get" PATH, and those that don't: The default jsut click through witout reading it intstall should do the most expected thing for don't-get-PATH folks -- i.e. they get access to the mosst recent version installed. It should be possible for do-get-PATH folks to customize the system (ideally without having to get the registry, too!) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 18 March 2016 at 20:35, Chris Barker <chris.barker@noaa.gov> wrote:
Not really. By "champion" I mean "take the lead" - i.e., pull together all the arguments, summarise them, produce a proposal, write a patch (or get someone else to write it) create the tracker item, get a core dev to support it and shepherd it through to being committed. At the moment, all we're doing is discussing possibilities, nobody's stepped up to take the lead. I get the feeling that some participants in the discussion might think that discussion is enough, but I've seen too many of these threads fizzle out because no-one is interested enough, or has enough time, to do the hard bits. I just wanted to be clear that I started this thread for a *different* proposal, which came to a conclusion that I plan (other commitments permitting) to get implemented. But I'm *not* sufficiently interested in this new proposal to take it forward, so someone else will need to step up at some point if the idea is to go anywhere. Paul
On 16/03/2016 17:17, Chris Barker wrote:
Then grab a third party tool that does the same job. I use the Rapid Environment Editor http://www.rapidee.com/en/about but I understand that there are others. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 15 March 2016 at 21:25, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
Yeah, it's unfortunately currently still off by default. Since it's sysadmins that don't like it being on by default, and they're better equipped to change it back than Windows users being introduced to the command line for the first time, I'd prefer to see that particular default flipped to be opt-out rather than opt-in. Educators are the folks best positioned to argue for that change, since you're the ones that have to deal with the fallout of beginners installing Python by clicking through the installer prompts without realising they need to request the automatic PATH modification.
The major & minor versioned executables exist on *nix if people want to use them, but tend to make scripts and instructions more platform specific than they need to be. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (22)
-
Alexander Walters -
Andrew Barnert -
Chris Angelico -
Chris Barker -
Chris Barker - NOAA Federal
-
eryk sun -
Ethan Furman -
Ian Kelly -
Jonathan Goble -
Koos Zevenhoven -
Mark Lawrence -
Michel Desmoulin -
Nick Coghlan -
Oscar Benjamin -
Paul Moore -
Random832 -
Stephen J. Turnbull -
Steve Dower -
Steven D'Aprano -
Terry Reedy -
Victor Stinner -
Zachary Ware