On Mon, Nov 20, 2017 at 3:24 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 20 November 2017 at 21:59, Chris Barker <chris.barker@noaa.gov> wrote:
> I don't understand any of this enough to have an opinion, so while I'd like
> to see py.exe be renamed python.exe, let's not let "the perfect be the enemy
> of good enough". So, if someone can make the case that they can restructure
> the whole py.exe / python.exe thing nicely in a way that will work, AND
> write the code to do it fairly quickly, then great!

I'm happy enough to modify the py.exe code to base its behaviour on
the name it's called with, as Steve suggested. I'm not sure if that
would require a PEP, but I'm willing to do one if it's felt that there
is a need. It should be possible to get that change in for 3.7.

very cool -- thanks!
 
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 :-) 

I honestly don't know - it's a cool idea, and I liked the idea of replacing the #! line and all that, but the truth is that people simple don't write scripts on Windows and expect them to "just work" the same way they do on *nix systems. And if you do distutils/setuptools "scripts" or "entry points" or whatever we are calling them, right, then you can write utility scripts and install them, and use them....

So ti comes down to: does anyone USE py.exe???

The fact that it's unique to Windows  makes it simply less discoverable, and the fact that Windows users aren't used to the whole #! line thing, means that as useful as it might be, it's not getting actual use.

In fact, I happened to be paying a lot of attention to this conversion because at the very same moment, a group of us are developing a python curriculum, and working on the "how to run a python file" part. We are producing platform specific instructions, but decided NOT to include the py.exe option for Windows users .. just more confusing things among a lot of confusing things!

So who does teach people about it???

Anyway, this whole thread has been about making the experience more platform-independent -- ideally users should see docs without Windows-specifc advice, and have it "just work" -- having a python3.exe  would make that more likely, so let's do that.

If we could py.exe enhanced and then use it instead of python.ex,m that would be great. Though I at least still have no idea of that's possible.

But I don't see why we couldn't make a pyton3.exe NOW (in py3.7) that is a copy (Or link, still don't get linking on Windows...) of python.exe, that would help the situation, and if at some point the in the future, python.exe, python3.exe and py.exe all become the same thing, great!
 
I think the launcher change is worthwhile in its own right. Even if we
don't install any aliases by default, users will be able to manually
add them.

sure -- but no one would -- or not really no one, but it would become maybe even a worse hassle of the same thing not working everywhere.

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.

simple, straightforward, and it CAN help.
 
> Otherwise, let's at least get a python3.exe into 3.7 -- and ideally into
> updates to 3.5, 3.6, and (python2.exe in this case, 2.7)

It's not going to be acceptable for 3.5, as that is now in security
fix only mode. I'm not certain it's even acceptable for bugfix-only
releases. It's a backward incompatible change (3.6.3 has no
python3.exe but python 3.6.4 does) but maybe an acceptable one - we'd
need feedback from the 3.6 and 2.7 release managers on that.

Fine -- we can leave that for future discussion....
 
Also, I'm assuming here you mean "create a copy of python.exe called
python3.exe". If we do that, we risk making it harder to later switch
to making "python3.exe" a link to the launcher - for the same reason
that making "python.exe" be an alternative name for the launcher is
problematic right now.

I'm lost -- how does it make it any harder, rather than exactly the same ???
(except two changes, rather than one...but they are the same change)

> And maybe make "add to PATH" be the default in the installer.

I'm not willing to contradict Steve on this one.

I didn't know he'd made a clear statement about it.

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...
 
or starting
their migration from 2.7 with 3.7) unpleasant,

why would that be a problem????

Though we may need a "python2.exe" executable for that to work well :-(
 
The history of how we added Python to PATH across various versions is
messy and inconsistent. Add to that other distributions (Anaconda,
ActiveState) making different choices and adding yet more
inconsistency, means that anyone who *isn't* a brand new user probably
already has a tweaked, and likely fragile, setup.
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."
 
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.

It's not easy, but at least it stands a
chance of breaking out of the cycle we're currently in, of switching
back and forth between "add to PATH" and "don't add to PATH".

It also seems completely orthogonal to the "add to PATH" question -- having this nifty new launcher setup, but not on a newbies PATH where they can use it, isn't going to help at all.
 
> Those are quick and simple to do, result in little disruption, and make the
> whole cross-platform thing more manageable.

They aren't that simple. I've already discussed "add to PATH". And if
we add python3.exe, we have to consider questions like will venv be
modified to include it in virtual environments? Will virtualenv?

what do those systems do on *nix? do exactly the same thing on Windows. Done.

Also -- I don't much care -- I want newbies that aren't using virtual environments to have a better expeience -- virtualenv pretty much solves this issue IF they are being used.

 
 
"Although never is often better than *right* now" is the relevant
Zen here, not "Now is better than never" (nobody's suggesting we
*never* fix this).

if we take long enough, everyone will be using python3 anyway :-)

-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