roy at panix.com
Mon Nov 10 14:36:54 CET 2014
In article <i0h06a9pj8h3olo5rnrgc64i7ckpvtvti6 at 4ax.com>,
Steve Hayes <hayesstw at telkomsa.net> wrote:
> I have a book on Python that advocates dividing programs into modules, and
> importing them when needed.
Yes, this is a good idea. Breaking your program down into modules, each
of which does a small set of closely related things, makes it easier to
manage. You can test each module in isolation. When you look at your
version control log, you can see just the changes which apply to just
that module. When somebody new joins the team, they can learn about
each module one at a time.
None of this is specific to Python. Good software engineering practice
is to break large applications into manageable pieces. The vocabulary
may change from language to language (module, package, class, library,
dll, etc), but the basic concept is the same.
> But I understand that Python is an interpreted language, and If I wrote a
> program in Python like that, and wanted to run it on another computer, how
> would it find all the modules to import at run-time, unless I copied the whole
> directory structure over to the other computer?
Yes, exactly. When you deploy your application someplace, you need to
include all the things it depends on. In the simple case of a few
python files (say, a main program and a few modules that you're
written), the easiest thing to do might be to just clone your source
repository on the other machine and run it directly from that. Another
possibility would be to package up all the files in some sort of archive
(tar, zip, whatever) and unpack that wherever you need it.
You will also have to set up a correct environment. This usually means
having an appropriate version of Python already installed, plus whatever
third-party modules you use.
More information about the Python-list