Maintainability (was Re: Stackless & String-processing)

Aahz Maruch aahz at netcom.com
Thu Jul 22 19:22:35 EDT 1999


In article <37974758.FF2DAE55 at callware.com>,
Ivan Van Laningham  <ivanlan at callware.com> wrote:
>Aahz Maruch wrote:
>> 
>> I'm afraid I can't agree that there's *ever* a good time to use "from
>> foo import *" in a multi-programmer environment.  Too often, you have a
>> programmer new to a particular chunk of code trying to debug it; not
>> knowing exactly where a method/function call is coming from vastly
>> increases debugging time (particularly when there are hundreds of
>> modules and scripts).  If you want to use an unadorned class/function,
>> you can just take the trouble to explicitly list it as "from foo import
>> bar, baz".
>
>All true, except for perhaps Tkinter.  And my soon-to-be-released
>mayalib-1.2.  Both are specifically designed to use 'from xxx import *'
>and both carefully refrain from polluting your namespace.  But possibly
>you don't use Tkinter in your projects, Aahz?  (I think I can safely
>assume you don't use any Mayan dates. ...;-)

The point is that a programmer looking at a traceback has no way of
knowing from looking at a line of code in isolation where the
function/class comes from.  At least with "from foo import bar" a search
through the source will discover which module/package bar comes from.

Although polluting the namespace is an issue (and as Greg points out, if
someone subclasses, you definitely do have a greater likelihood for
namespace collisions), I'm trying to hammer on the idea that specifying
where things come from is a critical issue.
--
                      --- Aahz (@netcom.com)

Androgynous poly kinky vanilla queer het    <*>      http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6  (if you want to know, do some research)




More information about the Python-list mailing list