[Python-Dev] Package Style Guide

Peter Funk pf@artcom-gmbh.de
Thu, 8 Jun 2000 11:35:14 +0200 (MEST)


Hi Andy,  

> Thanks for all the replies.  
> We really need a 'style guide' on package use, 

On 'import', packages and modules:
----------------------------------
You should definitely have a look at the approach used by Greg
McFarlane in his 'Pmw' package.  In particular at his PmwLoader class
and the Pmw.def.  For my own project I've simplified and somewhat
generalized his approach to dynamic and lazy importing.  I posted a
preliminary implemantation of this to comp.lang.python a while ago
but didn't got much feedback.  May be due to fact, that I had to repost
the thing, because the TABs went wrong in the first try :-(

[...]
> Is this style evil?  If so, why? 

I believe it will get really hard to come up with a 'namespace style guide' 
which everybody can aggree on.  But who cares: let's start a rant:

-->  IMO 'from ... import ...' is EVIL and its use should be banned!  <--

Why?  Because if software becomes bigger (> 100k LOC), these
unqualified names definitely become a maintaince nightmare, since you
didn't know what names are defined in the module you are currently
staring at and what names come from the "outside world".

I believe Python inherited two of its three forms of import syntax at 
least in part from its anchestors Modula-2 and Modula-3.  

My perception of this import-problem may be blurred by programming in
Modula-2 in our company since 1985, where the code base now is about ~1
Mio. LOC.  Some of the older code contains still modules using a lot of
'FROM foobar IMPORT ....;' lines in the header.  These have usually
been harder to read and understand by new employees than those having
'IMPORT foobar;' in the header and than using 'foobar.component'
everywhere in the code body below.

from .... import * is *EVEN MORE EVIL*.

Well: at least if people use 'from' to import arbitrary objects and
classes.  Using 'from package.subpackage import module' is an idiom,
with which I can live with comfortably.

> Should test scripts all be moved out of the package?  

This would defeat the use of Tim Peters wonderful 'doctest' module.
I'm still thinking, 'doctest' should be made part of the standard
library in order to give the publicity this elegant approach deserves.

Regards, Peter