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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4