(slightly OT): Python and linux - very cool

[James J. Besemer]

"Delaney, Timothy" wrote:

> How can they be? Any time they export *anything* it may clobber the
> namespace of the importing module.

If you're saying it's impossible in general to protect
against any and all clashes, I would have to agree.

My point was that in many cases module designers
can do a better job protecting their code and their
customers against problems such as the specific one
described.  Seems the careful designer would instinctively
take care to see that internal functions and state are so
protected.  If there was no "import *" then the module
designer would have no reason to care but since the
hazard exists, the responsible designer will guard
against it.  This is a natural part of programming
(at least for programming professionals).  And in
any case it seems irresponsible to foist problems
off on the user if you don't have to.

You don't agree?

Or are you saying it simply isn't worth the extra effort?

In looking through the library, I see some module designers
are quite scrupulous about hiding internal names.  Others,
particularly older modules, are careless by comparison.
For still other modules, e.g., UserDict it's a moot point as
there's nothing to hide.  Increased hiding seems to be
a trend in newer modules, a healthy trend IMO, one
which I think we all should encourage.

> IMO it is up to the user to ensure that they only import what they need ...

No argument that the user has to take responsibility
for what he's doing.  And I agree that general advice to
the newbie should be "don't 'import *'".

Nevertheless, module designers can and should take steps
where possible to make the user's life easier.  Eliminating
possible name clashes IMO is a characteristic of a quality
implementation and more responsible than blithely
foisting the problem onto the newbie user.

> from ... import * is IMO one of the biggest warts of Python as it can cause
> very obscure bugs.

In my view the actual wart is in blithely exporting everything
by default.  Most languages and designers rely on modules
to hide information.  It's a necessary feature of large scale
programming and module boundaries are the most common
place where information hiding is required.  Most languages'
module implementations require an express 'export' or 'global'
declaration to explicitly indicate those portions which are to be
made public.  Rather than have the ignorant user decide what is
public and what is private, the module designer should do this.
The recent addition of the "__all__" hack would appear to
acknowledge this requirement.

A proper export syntax and semantics would address
many of the aforementioned problems and would be
IMHO a superior solution.  Requiring an explicit

    export name1, name2, ...

with all other names remaining private, would have been
a vastly superior solution, certainly it would be cleaner
than the recently added

    __all__ = "name1 name2 ..."

hack and the earlier (original?) under bar prefix hack.
(Though, in all fairness, this may have been intended to
be a stop-gap measure, with the expectation that it
eventually would be replaced by a first class feature.)

I would STILL retain the existing import semantics that
would allow you to winnow the list of symbols down even
further (which just seems handy) and provide for
disambiguation of unavoidable name clashes (absolutely
necessary, though alternative mechanisms could be devised).

If course, this doesn't solve all the problems.  There's no
way to ensure that essential names from two arbitrary
modules don't clash and some way to keep them separate
will always be needed.

But I submit that better module design could eliminate
most if not all of the "subtle" bugs referred to that are
so hard to track down.

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com