[Python-ideas] Make py.exe default to Python 3

[Stephen J. Turnbull]

Paul Moore writes:
 > On 16 March 2016 at 17:17, Chris Barker <chris.barker at noaa.gov> wrote:

 > > 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...
 > 
 > In theory, this makes sense to me.

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.