<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 October 2017 at 05:57, Alex Walters <span dir="ltr"><<a href="mailto:tritium-list@sdamon.com" target="_blank">tritium-list@sdamon.com</a>></span> wrote:<br><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-">> While I completely agree with this in principle, I think you<br>
> overestimate the average beginner.<br>
<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.  If this is an insurmountable problem for the newbie, maybe they really shouldn’t be attempting to program.  This field is not for everyone.<br></blockquote><div><br></div><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, 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>