Home Original page

Organizing Python Code

Quinn Dunkan quinn at seniti.ugcs.caltech.edu
Thu Oct 5 16:33:17 EDT 2000 
On Wed, 04 Oct 2000 23:33:48 +0100, Russell Wallace <rwallace at esatclear.ie>
wrote:
>Tres Seaver wrote:
>> Just as '#include "kitchensink.h"' reduces maintainability in a
>> C/C++ program (where 'kitchensink.h' then #includes all the other
>> project headers),
>
>I find it improves maintainability to not have to keep editing the list
>of #include or import directives at the top of each source file.
>
>> your strategy is going to cause the future
>> maintainer of your code (likely, you!) to take your name in vain
>> after chasing down a few obscure buglets which it enables.
>
>What obscure buglets?  The only issue I'm aware of is conflict between
>identifiers defined in two or more modules and as far as I'm concerned,
>if I have duplicate public identifiers I want to know about it
>immediately rather than wait until something _does_ need to access both
>of them.  I've never had any problems with this strategy.

Because of python's dynamicism, you could have two conflicting identifiers and
not notice until it, say, corrupted your database.

And if you're not using *, you *can* use both of them and it's clear which
one you mean.  In fact, many of my modules have duplicate names on purpose
because the module name provides the necessary context.  Just a C libraries
often define:

png_open()
png_mangle_colors()
png_do_this()
png_do_that()

python libraries can say:

png.open()
png.mangle_colors()
png.do_this()
png.do_that()

That 'open' would cause all sorts of confusion after a import *.



Also, this is where python's two-namespace thing is nice: I can only generally
remember four or five names at once.  If I have two global constants, two
formal parameters, and one local value (or any other combination), I'm pretty
comfortable (although constants are easier on the brain than mutants).  Any
more than that and I start getting nervous.  If I see an unqualified name, I
can usually quickly figure out where it's coming from.  If I had done a
'from spam import *' somewhere, I'd have to go find spam.py and check that,
too.  If I used * extensively, I'd have to potentially check every single
source file just to know where one name comes from, and that's too much work
for me.  Given python's dynamic nature, it very important to me to be able to
figure out where a name comes from, because I may not even know what type it's
supposed to be just looking at it.
More information about the Python-list mailing list