In article <i0h06a9pj8h3olo5rnrgc64i7ckpvtv...@4ax.com>, Steve Hayes <hayes...@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. -- https://mail.python.org/mailman/listinfo/python-list
