Newbie edit/compile/run cycle question

[MartinRinehart at gmail.com]

Bruno,

Please explain why the NOP import is a GoodThing. Use small words
please. I'm not as young as I used to be.

I didn't know about reload(), but now that I'm informed on that point
I'm still using

os.remove('foo.pyc')
reload(foo)

A single command to do that would be nice.

Martin

Bruno Desthuilliers wrote:
> MartinRinehart at gmail.com a �crit :
> > Thanks for all the help. Thought I'd spend my newbie days right in the
> > Python shell (there's lots to test when you're just starting) but I
> > guess that's not going to happen.
> >
> > Everyone told me to get out of the Python shell, one way or another.
>
> Everyone told you to not use the shell that way - which is not exactly
> the same thing. The shell is just great for exploring things. Like
> quicly testing APIs, expressions, syntax etc before or while coding, or
> inspecting the state after execution of your code (using the -i option),
>   etc... A common (AFAICT) practice is to have some 'test setup' code in
> a .py file, that you use to import the modules under test and init a
> couple vars, then launch this script with the -i option. Emacs
> python-mode let you start a python shell in another frame, and eval
> either your whole file or just parts of it in this shell.
>
> > OK. But this means that every execution must first load Python, then
> > import my stuff.
>
> Just like it does with Java - but it might be much faster.
>
> > Import becoming a NOP after first use in the shell is
> > a six-legged feature, at best.
>
> import becoming (almost) a NOP after first effective import is the
> RightThing(tm) to do. If you want to reload a module, you have to ask
> for it explicitely - using reload(module). But this won't affect already
> instanciated objects, and can lead to very strange situations - hence
> the common pattern of the setup script + the -i option.