[Python-Dev] Add __exports__ to modules

Tim Peters tim.one@home.com
Mon, 8 Jan 2001 02:05:46 -0500


Well, I like __exports__ (but not some details of the patch, for which see
my SF comments).  Guido is aware of the optimization possibilities, but
that's not what's driving it.  I don't know why he likes it; I like it
because the only normal use for a module is to do module.attr, or "from
module import attr", and dir(module) very often exposes stuff today that the
module author had no intention of exporting.  For example, if I do

    import os
    dir(os)

under CVS Python today, on my box I see that os exports "i".  It's bound to
_exit.  That's baffling, and is purely an accident of how module os.py
initialization works when you're running on Windows.

Couple that with that I've hardly ever seen (or bothered to write) a module
docstring spelling out everything a module *intends* to export, and an
__exports__ line near the top (when present) would also automagically give a
solid answer to that question.

modules aren't classes or instances, and in normal practice modules
accumulate all sorts of accidental attrs (due to careless (== normal)
imports, and module init code).  It doesn't make any *sense* that os exports
"sys" either, or that random exports "cos", or that cgi exports "string", or
... this inelegance is ubiquitous.

In a world with an __exports__ that gets used, though, I do wonder whether
people will or won't export their test() functions.  I really like that they
do now.

or-maybe-it's-just-that-i-like-modules-that-*have*-a-
    test-function<wink>-ly y'rs  - tim