[Python-ideas] install pip packages from Python prompt

[Chris Barker - NOAA Federal]

> 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.


I actually take this approach myself in my classes. However, I also have as
prerequisites for my classes:

Some Experience in some programming language

And

Basic familiarity with the command line.

I then let them use whatever dev. Environment they want, while supporting
and recommending a good editor and the command line.

However, If people want to learn python that don’t have those
prerequisites, then we suggest a different class designed for total newbies.

In THAT class,  we use a more proscribed dev environment so that everyone
is doing the same thing in the same way. It was IDLE, and has lately been
PyCharm.

And the intro to data analytics class uses Anaconda and the Jupyter
notebook.

My point?

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,


Sure, but who is “we”? I think “we” is the python community, not the
cPython developers.

So providing an environment that makes it easy and obvious to install
packages is a great idea, but I think it’s the job of IDEs and other higher
level tools, not the REPL.

If we need to add a feature to Python itself to make it easier for IDEs and
the like to implement dynamic package adding, then by all means, let’s do
it.

Final note:

I DO see a lot of questions ( on mailing lists, etc) from folks that try to
type “pip install something” at the python command line.



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

_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171031/807d43e8/attachment.html>