Organizing Python Code

[Russell Wallace]

Quinn Dunkan wrote:
> 
> 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.

Theoretically yes, but the same kind of argument can be applied to any
form of dynamism - in particular, it's the same one the static typing
advocates use.  In practice I find it's not a big issue, since errors
like this generally show up quickly in testing.

> 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 *.

Ah, yes I see; if you're using that style, the explicit qualification is
actually helpful, it lets you use shorter identifiers without
ambiguity.  I find my public identifiers tend to end up being unique
anyway without any particular effort to make them so, so I don't need to
add the module name.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwallace at esatclear.ie
http://www.esatclear.ie/~rwallace