[Excuse any attribution errors, the quoting appears to have got badly messed up somehow]
On 21 November 2017 at 06:21, Steve Barnes gadgetsteve@live.co.uk wrote:
On 21/11/2017 00:32, Chris Barker wrote:
I don't know what would be the best approach for adding copies/links of the launcher under other names, though.this is the thing -- I wonder if py.exe has been a success at all :-)
A lot of people, on windows, are using py.exe and pyw.exe without realising it - the default behaviour of the recent installer is to associate py.exe with *.py and pyw.exe with *.pyw so any user that is running python code by just typing the name of the file, or double clicking it, will be using it.
I use the py launcher a lot. Often just as "py" or "py -3.6". It certainly isn't just limited to use via shebang lines.
I will say that I don't see beginners using it as much. That's probably because there's so much documentation that says "use the python command to start Python". That is of course an argument that we should make the canonical command "python" rather than "py", but it doesn't mean that if people find the "py" command they won't use it. There's not a lot of evidence that isn't anecdotal either way on that latter point.
So ti comes down to: does anyone USE py.exe???
As above.
And me.
we need th=e basic advice given out to *nix users to work:
if you type "python" at the command line, and get python2, then you can type "python3" to get python 3.
Um, we need the basic advice given to *everyone* to work. Insisting that advice has to be "what Unix people do right now" is not the only option. The advice "use python to run your default Python interpreter" is too entrenched to change. The python2 and python3 aliases are a platform-specific hack to get around the fact that some Linux distributions couldn't switch the default Python to Python 3. Most of the beginners I work with have no experience on Unix and no awareness of python2/python3 commands.
"If you run python at the command line and get the wrong version of Python, then..." - In that case you already have multiple versions of Python on your system, and by the definitions we've been working to here, you're an advanced user so you can fix it yourself.
Obviously, that's too harsh a stance for us to take. But let's not ignore the fact that Unix users are typically *already* having to deal with multiple versions of Python, and are typically more familiar with command lines than Windows users. So there's no guarantee that a solution that works for them is usable for Windows users who've never used Python or the command line before, who downloaded Python 2.7 and installed it, were then told "no, you should be using Python 3", and installed 3.7, and now don't understand why "upgrading" didn't uninstall the old version, what they need to do to work with Python 3, etc...
One of the nice things about embedding the behaviour into the launcher is that if the user/admin has installed a python that includes it it provides the behaviour for python installations that were already present and discoverable even if they didn't have it so if you have python 2.5 then after you install something with py.exe you can, currently, use py -2.5 to run it, (or py -2 if it is the only python 2).
+1. This is the biggest benefit for me. Also the fact that all the older Python versions *don't need to be on PATH*. Having multiple versions of Python on PATH is a bad thing (because of the Scripts directory - if you want, I can explain in detail, but it's a side issue for now).
I'm not willing to contradict Steve on this one.I didn't know he'd made a clear statement about it.
I am not sure that I spelt it out well enough but my personal feeling is that the installer should, (and I am reasonably sure that it should capable of this), default to add to path IF there is not a currently available python, (discoverable), and either default to don't add or prompt the installer if there is.
My apologies - I was unclear. I meant Steve Dower, who maintains the installer, and who has strongly stated that the way the Windows PATH works (separate system and user parts) makes sensible "add to PATH" behaviour impossible. The reasons have all been described multiple times, and I won't go into them again. Search the archives if you want to see the details. Suffice it to say that wishing it was easy to "just add Python to PATH" doesn't make it so...
Of course the whole add to path or not becomes moot if the py.exe launcher is present as it is installed on the path, (C:\Windows), and then tries very hard just to "do the right thing".
That's why I prefer this option. There are still issues to address (such as the Scripts directory), but it's much easier to keep the complexity manageable with this approach.
But if people that understand these things say it's a bad idea, then it's a bad idea. But we SHOULD make sure we are considering not just what could go wrong, or how often it could go wrong, but who it is going to go wrong for...
i.e. making it "do the right thing" for newbies is much more important that making sure it doesn't "do the wrong thing" for more experienced folks that can uncheck a box, or clean up their PATH after the fact....
There are too many not-uncommon cases that we could mess up badly here. It's the right choice for "make new users' experience as easy as possible", but if we do this at the cost of making the experience of people upgrading to 3.7 (possibly by installing 3.7 to gradually switch over,then you uncheck the box -- and if someone is installing 3.7 to test it out, they SHOULD be a experience enough to uncheck a box...
But I (as an advanced user) don't *want* to uncheck the box. I *do* want 3.7 to be my default Python. But if I previously had 2.7 as my default, and that's in the *system* part of PATH, then checking the box *doesn't work* - Python 2.7 is still my default. OF COURSE I have enough knowledge to fix the issue. That's not my point. My point is, do we want experienced Python users' first experience with Python 3.7 to be "the installer didn't work right", or "installing 3.7 broke my system, and I had to fix it manually", or something similar? Experienced Python users on Windows have been remarkably tolerant over recent years of our continual changing of where we install Python, whether we add to PATH by default, etc. At some point we need to stop, think things through, and get it right once and for all. Or at least agree to stick with what we decide for longer than a couple of releases.
We're not doing them any favours by adding another new behaviour.I'm not trying to do them any favors -- I'm trying to do the favors for the newbies.. and YES, at the expense of people with "tweaked, and likely fragile, setup."
OK. Maybe "not doing them any favours" is not as well known a phrase as I thought, sorry. What I meant was we're repeatedly penalising such users and we need to stop. We don't need to cater for their specific environments (they know how to do that themselves, and have done so). But we do need to stop breaking their setup every release.
We need *another* solution here. Not just variations on the existing mess. That's why I like Steve's suggestion of making the launcher into the canonical entry point.only if it's named "python" (and python3) -- what we DON'T need is a different way to do it on Windows -- that's what we tried, and I thin it's failed.
"python" yes. Not so much "python3", which I don't believe is a solution anyone *likes* - it's just an expedient for a specific Unix issue. (If you don't believe me, there's plenty of issues on the pip tracker that boil down to Unix users getting confused over which Python version they are executing, so certainly "python3" isn't a perfect solution, or even a particularly good one IMO).
Paul