[Python-ideas] install pip packages from Python prompt
tjreedy at udel.edu
Wed Nov 1 01:46:25 EDT 2017
On 10/31/2017 10:41 AM, Nick Coghlan wrote:
> On 31 October 2017 at 05:57, Alex Walters
> <tritium-list at sdamon.com
> <mailto:tritium-list at sdamon.com>> wrote:
> > While I completely agree with this in principle, I think you
> > overestimate the average beginner.
The average Python beginner may have a decade or more experience
interacting with computers by voice, gestures, fingers on a screen,
mouse clicks and movements, joystick controller clicks and movements,
and single key presses. This includes using a word processor. They may
or may not have consciously learned (or remember) anything about natural
language grammar. Python may well be their first experience with a
formal language grammar and a picky interpreter.
> Nope. I totally get that they don’t know what a shell or command
> prompt is.
A shell is a program in which users issue instructions one at a time as
sentences in a formal language and wait for the response before issuing
> THEY. NEED. TO. LEARN.
Yes. But what shell should people who want to learn Python learn first?
Interactive python, which comes with a 'using' manual besides a tutorial
and two reference manuals?
Or, on Windows, Command Prompt, which runs a sparsely documented unnamed
language, has no tutorial, and has mostly been replaced by File Explorer?
One can just as well or better learn the idea of a REPL with formal
language input from Python first. Once one has learned interactive
Python, learning to use other shells should be straightforward. It
should not be too hard to convey that a different language with a
different syntax and different built-in commands requires a different
> Hiding it is not a good idea for anyone.
Tell that to Microsoft, which in Win 10 removed command prompt and other
'expert' tools from the regular start menu.
> 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
My daughter learned Python and IDLE (from me) about 5 years before she
had to learn about Command Prompt. (In between, she had courses that
used the Racket and Jave/Eclipse IDEs.) The notion that she should have
been forced to learn an inferior and useless (to her) shell first is to
> 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.
Amen. At least 99+% of my interaction with the hg repository and my
clones thereof was through TortoiseHg and its Workbench gui.
> 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
I believe that this was suggested on idle-dev and rejected by Guido as
an expert feature, or perhaps as abbreviating and thereby encouraging an
expert usage. I will let him say what he thinks now.
I have considered adding 'Run OS Command' to the Run menu, but I mostly
do not see the point for a Python shell or REPL. If one knows what to
type after '!', one can just as well click the appropriate icon and
enter the command there. Or use os.system or subprocess. What am I
> 4. Having IDLE call that importlib API and warn about any stale modules
> after each command line operation
This seems heavy handed, usually unnecessary, but also inadequate. One
can now manipulate site-packages while running a Python shell in ways a
shell will not know about. One should then either start the shell
manually or take the consequences.
As it is, IDLE restarts the user process each time one runs code from an
editor. Or one can explicitly restart the user process, without exiting
IDLE, after installing or updating modules.
One objection to the latter has been that restarting, even on IDLE,
clears more than one might want. I am working on a separate proposal
that would make it easier to regenerate a workspace.
Hardly mentioned in this thread is that command line apps in general and
pip in particular are not easily usable by many people. One needs to
use a particular app regularly or have an unusually good memory for
fiddy details or a high tolerance for reading and ability to understand
reading -h output. That is why I think a pip gui would greatly help.
If nothing that directly goes in the stdlib, other than ensurepip, can
depend on pip and its api, a helper module could be installed from pypi
along with pip (by ensurepip!).
A pip wrapper, gui or not, could alleviate the following problem using
pip in Windows. There are up to date Windows binaries on Christopher
Gohlke's site, https://www.lfd.uci.edu/~gohlke/pythonlibs/. It
currently has 32- and 64-bit builds for 2.7, 3.4, 3.5, and 3.6, as
appropriate, for perhaps 450 packages. At least some are source-only on
pypi. The site is not a pip package index, so the wheels must be
downloaded first before being installed by pip.
As for the subject of this thread: I intended that the pip gui that you
and Ned Deily vetoed should, unlike pip itself, be runnable from python
with "import pipgui; pip.main()". An import module can detect whether
is it being run directly with Python or IDLE and, if sys.modules is
modified, adjust its exit message or action accordingly.
The main problem with pip that I have seen on Stackoverflow is that
people run pip on a command line with a binary different from the one
that they run IDLE with, and then post 'X imports Y, IDLE does not'.
The easiest way to ensure that something is installed for the binary
running IDLE is for IDLE to run something with its sys.executable.
Terry Jan Reedy
More information about the Python-ideas