Newbie edit/compile/run cycle question

[MartinRinehart]

I'm a java guy used to the effective edit/run cycle you get with a
good IDE.

Today I'm writing my first Python, but can't seem to find the way to
use Python's inherent edit/run cycle.

I edit my source, import it into Python, run it. Fine. Then I edit
again, but the next import doesn't notice that a new compile is
needed. I'm making a little progress (very little) by exiting/
reentering Python after each edit. Ugh.

What don't I know that I should know to just edit/run, preferably at
the tap of a function key?

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

I'm a java guy used to the effective edit/run cycle you get with a
good IDE.

Today I'm writing my first Python, but can't seem to find the way to
use Python's inherent edit/run cycle.

I edit my source, import it into Python, run it. Fine. Then I edit
again, but the next import doesn't notice that a new compile is
needed.

This is not an accurate definition of what happens. The import mechanism
keeps already imported modules in cache (for obvious reasons). wrt/
"notice(ing) a new compile is needed", it's not the import mechanism's
duty, but the VM one's.

I'm making a little progress (very little) by exiting/
reentering Python after each edit. Ugh.

Java doesn't have an interactive shell, so there's no real parallel
here, but anyway: with Java, you have to restart a Java VM each time you
run your code. Why do you hope something else with Python ?

What don't I know that I should know to just edit/run,

Do what you would do with Java:

$ python yourprogram.py

Or if you want to inspect the state after execution (something you can't
do with Java):

$ python -i yourprogram.py

preferably at
the tap of a function key?

Use an IDE then. Or a real code editor like emacs - it's python-mode is
way more powerful than what I saw in any IDE.

 

[Dennis Lee Bieber]

I'm a java guy used to the effective edit/run cycle you get with a
good IDE.

Today I'm writing my first Python, but can't seem to find the way to
use Python's inherent edit/run cycle.

What are you using? PythonWin, IDLE, even SciTE all have commands to
spawn&run the current edit window. I would suspect the PyDev plug-in for
Eclipse also supports that.

I think the behavior of import is a FAQ -- only if the module name
is NOT already in the Python interpreter list of modules will it read
the file, after that it just retrieves the objects of the previously
read module from the cached store.

Depending upon what you are doing, reload() may be your friend --
but note that it won't update any existing objects that have references
to the old module object.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Terry Reedy]

| What don't I know that I should know to just edit/run, preferably at
| the tap of a function key?

In IDLE, which come with Python, it is F5. (See Options/General/Autosave)
Startup is about .1 sec since the program runs in a window of the same
interpreter.
Stand-alone editors require longer to start a separate interpreter,
but then you have a clean new interpreter that is not running TK or
anything else.
Your choice. Have fun.

If you run a separate interpreter, you might benefit from also having an
interactive interpreter window open in which to run quick experiments to
check names or syntax you are not sure of. This comes with running idle.

tjr

 

[MartinRinehart]

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.
OK. But this means that every execution must first load Python, then
import my stuff. Import becoming a NOP after first use in the shell is
a six-legged feature, at best.

 

[Arnaud Delobelle]

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.

It would be a shame not to use the shell.

Everyone told me to get out of the Python shell, one way or another.
OK. But this means that every execution must first load Python, then
import my stuff. Import becoming a NOP after first use in the shell is
a six-legged feature, at best.

Don't jump to conclusions too early.

In the shell, type 'help(reload)'. This might help.

 

[Bruno Desthuilliers]

(e-mail address removed) 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.

 

[Diez B. Roggisch]

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.
OK. But this means that every execution must first load Python, then
import my stuff. Import becoming a NOP after first use in the shell is
a six-legged feature, at best.

Being a Java-guy you might thing that starting a runtime environment is
a costly operation. Trust me - with python it isn't. Starting the python
runtime usually takes fractions of a second.

If you want to work with the REPL (read/evaluate/print-loop), make sure
you install rlcompleter2. Google for it - it makes working with the
interpreter much easier.

However, I also recommend you to use small scriptlets to test out things
- I always have a shell open, and with

alt-tab

switch to it. Arrow-Up gives me the last commandline (e.g. python
/tmp/test.py) - and then hitting return will execute it.

This costs about 2-3 seconds, and spares me the troubles of misspellings
in larger statements and the like. And some of the nastier aspects of
reload (google for reload and my name to see a recent thread why I don't
recommend it)

Diez

 

[MartinRinehart]

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

 

[Diez B. Roggisch]

Bruno,

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

Because otherwise every import would result in overhead without any benefit.
Think of a module like this:

--------

A_GLOBAL_VARIABLE = extremely_costly_initialization_of_cache_contents()

--------

You only want that to happen once.

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.

You can create your own function that does this.

def better_reload(module):
import os
if os.path.exists(module.__file__) and module.__file__[-3:] == 'pyc':
os.remove(module.__file__) # attention - you might want more checks
reload(module)

Then you can put that into a file, e.g.

~/.pythonrc

and point the environment-variable PYTHONSTARTUP to that file.

Diez

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

Bruno,

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

Each module that need access to another module must explicitely import
it. This means that, in a typical program, your main script will import
a couple modules, each importing other modules, etc. Chances are that
some modules - and not necessarily light-weight ones - may end up being
imported dozens or more times.

Now the import statement does 2 things : first load the module, then
inject it in the current namespace. Obviously, the costly operation is
the first one, and obviously it doesn't need to be done more than once
for a given process. I'd even say it should *not* be done more than once
for a given process, since reloading a module doesn't affect objects
using the already existing code.

So caching the module on first import is obviously the right thing to do.

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)

Mmm... I stopped using the reload function many years ago - in practice,
it's the perfect way to go on wild goose chase for bugs that don't
even exist - but IIRC, you shouldn't have to manually remove the .pyc file.

A single command to do that would be nice.

That was the purpose of the reload function AFAICT. Now it has proven to
be such a disaster in practical use that everyone and her sister found
better ways - like the ones that have already been suggested here.