[Tutor] modular programming help
Fri, 08 Feb 2002 11:17:27 -0800
>The way your teacher is using the word "module" is different from the way
>that we're using the word "module". It'll be a little confusing at first,
>but try to treat them as separate concepts.
Good advice from Danny, as usual.
A big problem in programming is "name collisions", where the
same word could point to different things, hence ambiguity.
The way Python, and other languages, resolve this issue
is to define a "namespace" and, in Python, a module defines
a namespace. So if you have a function named spam() in
moduleA.py, and a function names spam() in moduleB.py,
you can resolve the ambiguity by going:
import moduleA, moduleB
moduleB.spam("Takes different arguments",can="open")
Or you can rename the function upon importing:
from moduleA import spam as redspam # sounds gross
from moduleB import spam as bluespam # ditto
Now, this namespace problem happens in REAL LIFE [tm], so
you can think of your teacher using the word "module" in
a namespace defined by teacher.py, inside of which namespace,
the word module is roughly equivalent to function, or
subprocedure (BASIC is big on subprocedures -- a term
you won't hear much in Python circles).
So, mentally, when your teacher says "module", you can
think "myteacher.module" and when a Python programmer says
module, you can thing "pythonprogrammer.module" -- and in
that way, you resolve the ambiguity.
Note: the solution is similar to the file-pathname solution
in a file system. You can have the same file name all over
the place, but a *fully qualified* file name needs to be
unique, i.e. spam.py may occur in several directories, but
there can be only one root/usrs/myspace/stuff/python/spam.py
Expanding to the internet as a whole, you can prefix the
domain name and so on, by reversing the URL:
thereby becomes unique in the entire namespace of the
internet -- the convention used by Java programmers to
link to remote .class files and such.
It's all about how to have freedoms to use whatever names
inhouse (locally), but without sacrificing precise,
unambiguous references globally.
>Vocabulary often depends on context, even when we deal with
>programming languages. Don't worry too much; you'll be able
>to flip between them in time.
Exactly. And making these kinds of flips is what
compsci.languages.python.modules are all about.