[Python-ideas] install pip packages from Python prompt

[Nick Coghlan]

On 31 October 2017 at 05:57, Alex Walters <tritium-list at sdamon.com> wrote:

> > While I completely agree with this in principle, I think you
> > overestimate the average beginner.
>
> Nope.  I totally get that they don’t know what a shell or command prompt
> is.  THEY. NEED. TO. LEARN.  Hiding it is not a good idea for anyone.  If
> this is an insurmountable problem for the newbie, maybe they really
> shouldn’t be attempting to program.  This field is not for everyone.
>

We're not in the business of making judgements about who should and
shouldn't become Python programmers - we're in the business of making sure
that Python is accessible to as many people as possible by removing
irrelevant barriers to adoption, whether that's translating documentation
so folks can start learning with instructions in their native language, or
making it possible for them to defer learning the idiosyncrasies of the
Windows, Linux, and Mac OS X command line environments.

On the latter front, the details of the development interfaces offered by
traditional desktop operating systems may *never* be relevant to the new
generation of folks coming through that are learning to program by
manipulating remote coding environments on tablets and other app-centric
devices, just as most developers nowadays are able to get by without even
learning C, let alone any flavour of assembly language. Our role in this
process isn't to create future generations that think and work in exactly
the same ways we do, it's to enable them to discover new ways of working
that build on top of whatever we create.

Jupyter notebooks are a decent example of this, where the difference
between a Python statement and a "command line statement" is just an
exclamation mark at the beginning of the line - exactly where the backing
environment lives is mostly a hidden implementation detail from the user's
perspective.

Eclipse Che and other online coding environments are another case - there,
the "command line" is a different window inside the editor app (this is
also going to be a familiar option for heavy IDE users on traditional
desktop operating systems).

And putting it in those terms makes me think that we should explicitly
exclude the default REPL from consideration here, as we've long taken the
position that that *isn't* a good teaching environment, and you certainly
can't access it remotely without some kind of other service in front of it
to manage the network connection (even if that service is just ssh).

That means I now see a few potential RFEs from this thread:

1. An import system feature that allows a running Python program to report
a timestamp (with the same granularity as pyc file timestamp headers) for
*when* the currently loaded modules were last modified. This could be as
simple as a new `__mtime__`  attribute in each module to store that number.
2. A new importlib.util API to check for potentially out of date modules in
sys.modules (those where a freshly calculated module mtime doesn't match
the stored __mtime__ attribute)
3. Support in IDLE for Jupyter-style "!" commands
4. Having IDLE call that importlib API and warn about any stale modules
after each command line operation

The first two features would be about enabling learning environments to
more easily detect when the currently loaded modules may not match what's
actually on disk (hot reloaders already do this by watching for filesystem
changes, but we're currently missing a simpler polling based alternative
that will also pick up package updates).

The second two would be about enhancing IDLE's capabilities in this area,
as we *do* suggest that as a reasonable initial learning environment, even
though there are also plenty of alternatives out there now.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171101/6dd6aa04/attachment.html>