Maintainability (was Re: Stackless & String-processing)
Fred L. Drake
fdrake at cnri.reston.va.us
Fri Jul 23 10:35:55 EDT 1999
Skip Montanaro wrote:
> Some modules
> in the standard distribution were designed specifically to support this
> (types and Tkinter come to mind).
Greg Ewing writes:
> In the case of Types, it could easily have been designed
> differently. Writing Types.List would not be much harder than
> typing Listtype and would be easier to read as well.
I actually like the longer names on this one, but otherwise...
> As for Tkinter, I've gotten into the habit of always
> writing Tkinter.Button, etc. and I think the qualification
Though I think some of my co-workers disagree, I agree with you on
this one. Tkinter is a *terrible* module for the "import *" style.
James Henstridge's "gtk" module is much better about this, but enough
of the constants have short enough names that I won't use "import *".
Another problem of "import *" is that it makes introspection of a
module (using dir(), idle, whatever) more painful.
> So I wouldn't mind much if the * form of import
> went away, either. You can easily write a function
> which does the same thing if you really, really want it.
Yes.
Something that I'd like to see, that I don't think has been
mentioned for a long time, is some sort of "import ... as" statement.
I like qualifying the names from a module, but if I'm using them a lot
I want to give the module a short name. For instance,
import Tkinter as Tk
would be more comfortable, and is much more clear than:
import Tkinter
_tk = Tkinter
del Tkinter
Variants could include:
import package.module as pkgmod # pkgmod is the actual
# module, not the package
from package import module as pkgmod
# the same, possibly cleaner
from module import function as func
As I said, I haven't noticed this come up for a while, so maybe I'm
the only one, but I think this would encourage clarity and
"localizing" the names of imported modules (adding a leading _ so when
others "import *" from our modules their namespace isn't polluted too
much).
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
More information about the Python-list
mailing list