Python Classes and IDLE

[Alex Martelli]

<posted & mailed>

Graeme Matthew wrote:

> Sorry to bug u all, but im at the point of giving up and going back to
> Perl (much to my disgust as python is so clean !). I have been trying to
> get classes going, even with two bloody books, one by Wesley Chun and its
> just a nighmare, sometimes I have to close down IDLE and now I find out
> that it must be reading the .pyc file thats why when I make changes they
> are not taken into account. I eitehr have to delete the .pyc file or close
> down IDLE, if this is the truth then this will take ages to do a project,
> anyone got some advice ? thanks a mil

If you modify a module, called e.g. floop.py, which you have already
imported in some running program (such as any interactive interpreter,
including the one in IDLE), then in order to re-load module floop (so
getting the newer version as you just modified it) you must call the
built-in function reload.

reload(floop)

will go to the disk and load floop.py up again -- as a side effect it
will recompile it into floop.pyc if necessary (checking modification
times of the source and compiled files).

If you find you must remove floop.pyc in order for floop.py to be
recompiled when you reload it, there must be something weird going
on with the file dates and times in your machine (but in that case,
closing and restarting IDLE would do nothing for you -- while if
your problem was related to not having called reload, then closing
and restarting IDLE would work, BUT deleting the .pyc file would
do nothing for you -- so if you're reporting everything accurately,
there must be something yet stranger going on).


Assuming you're not doing reload, rather than having weird file
time problems on your machine...:

To expand on the reload issue: when you
        import floop
Python goes to disk for module floop only ONCE in a given program's
run -- then, it caches the module into sys.modules['floop'], so that
any further imports become extremely fast.  This is an absolutely
crucial optimization, since modules are often imported from many
other modules, and they _don't_ usually change -- for those cases
where they do change (typically during interactive development),
the built-in function reload was introduced.


I'm somewhat perplexed about what you say about "going back to Perl".
What interactive environment are you used to, in Perl, which
implicitly reloaded modules as you changed them, without needing
you to ask for a reload explicitly?  I thought Perl development
didn't normally use interactive development environments, but
rather an edit/run/edit/... cycle.  If that's what you are most
comfortable with, you can use it with Python, too -- write your
code into whatever.py and run it from a Dos command box with
c:\python22\python whatever.py or the like.  Each new run of the
program will pick up all then-current versions of modules, with
no need to reload anything.  In other words, while Python LETS
you use an interactive environment (and many people find that
quite productive), it doesn't FORCE you to -- the usual edit/run
cycle at the Dos or Unix commandline is still available, too.


Alex