Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Terry Reedy <tjreedy@udel.edu>
Newsgroups: comp.lang.python
Subject: Re: IDLE question: "you may still have to reload nested modules."
Date: Sun, 6 Mar 2016 14:58:11 -0500
Lines: 67
Message-ID: <mailman.2.1457294323.2226.python-list@python.org>
References: <68500ae6-0e37-43d2-b8d8-f9fffef72d41@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <68500ae6-0e37-43d2-b8d8-f9fffef72d41@googlegroups.com>
Precedence: list
Xref: csiph.com comp.lang.python:104172

On 3/6/2016 7:24 AM, alien2utoo@gmail.com wrote:
> Hello list,
>
> I am following "Learning Python: Mark Lutz" and came across following
> in chapter 3 few days back.

What is the copyright date on the copy you have?

> [quote] * You may still have to reload nested modules. Technically
> speaking, IDLE's Run->Run Module menu option always runs the current
> version of the top-level file only; imported files may still need to
> be interactively reloaded when changed. ... [/quote]
>
> It is slightly confusing, as to what it does imply. Could any IDLE
> guru clarify if I am missing or overlooking something?

IDLE currently, in its default mode, runs a module in a fresh separate 
process with a fresh sys.modules.  It closely simulates running a module 
from the command line with 'python -m mymodule'.  (One difference is 
that sys.modules is initially larger when run by IDLE.)

The quoted statement must have been written when IDLE always ran user 
code in the persistent IDLE process, as it still does if one starts IDLE 
with the -n option.  The current IDLE doc, in section 3.3. 'Running 
without a subprocess' (with -n) ends with

"Also, the environment is not restarted when Run/Run Module (F5) is 
selected.  If your code has been modified, you must reload() the 
affected modules and re-import any specific items (e.g. from foo import 
baz) if the changes are to take effect.  For these reasons, it is 
preferable to run IDLE with the default subprocess if at all possible."

Even if there were an attempt to restore sys.modules on F5, the comment 
would still apply if one edited and saved an stdlib module imported by 
IDLE.  I run into this when I edit an idlelib file.  I can run tests on 
the file in a separate process with F5, but to verify that the edit has 
the intended effect on IDLE itself, I have to restart IDLE itself.

If the quoted statement is in the most recent version of the book, it 
should be changed in the next one.

> If a needed-by-top-level-file module was changed after 'Run->Run
> Module', it would any way need to be reloaded.
>
> If it was changed between two "Run->Run Module" actions, won't it be
> automatically loaded afresh as a part of restarting Python
> interpreter and executing top-level-file [where is the question of
> reloading then?]?
>
> [Side observation: though F5 or "Run->Run Module" restarts Python
> interpreter with top-level-file afresh [indicated by dir() content
> before and after], the command history is not reset during this.

Commands are entered into and kept in the Shell in the IDLE process. 
There are not erased unless one closes Shell.  If there is an editor 
window that keeps IDLE running, and one hits F5, IDLE creates a new 
Shell with no history.

> This
> likely confirms the GUI process being separate than interpreter.]

The GUI process has its own interpreter, but you are correct that the 
user interpreter is normally separate.

-- 
Terry Jan Reedy