
On 10/31/2017 10:41 AM, Nick Coghlan wrote:
On 31 October 2017 at 05:57, Alex Walters <tritium-list@sdamon.com <mailto:tritium-list@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 another.
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 interpreter.
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 environments.
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 me absurd.
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 missing?
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