<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
</span>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.</blockquote></div></div></div></div></blockquote><div><br></div><div>I actually take this approach myself in my classes. However, I also have as prerequisites for my classes:</div><div><br></div><div>Some Experience in some programming language</div><div><br></div><div>And</div><div><br></div><div>Basic familiarity with the command line.</div><div><br></div><div>I then let them use whatever dev. Environment they want, while supporting and recommending a good editor and the command line.</div><div><br></div><div>However, If people want to learn python that don’t have those prerequisites, then we suggest a different class designed for total newbies.</div><div><br></div><div>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.</div><div><br></div><div>And the intro to data analytics class uses Anaconda and the Jupyter notebook.</div><div><br></div><div>My point?</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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, </div></div></div></div></div></blockquote><div><br></div><div>Sure, but who is “we”? I think “we” is the python community, not the cPython developers.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Final note:</div><div><br></div><div>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. </div><div><br></div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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. <br></div><div><br></div>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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">That means I now see a few potential RFEs from this thread:</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote">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)<br></div><div class="gmail_quote">3. Support in IDLE for Jupyter-style "!" commands</div><div class="gmail_quote">4. Having IDLE call that importlib API and warn about any stale modules after each command line operation</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Python-ideas mailing list</span><br><span><a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a></span><br><span><a href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a></span><br><span>Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a></span><br></div></blockquote></body></html>