[Greg Stein]
> hehe... adding __exports__ to your module is fine. Adding more
> crud to Python, in opposition to the "we're all adults" motto,
> doesn't seem Right.
My idea of what's Right is copied from my boss <wink>.
> Somebody wants to use "from foo import *" on a module not designed
> for it? Too bad for them.
How is someone supposed to know whether a module "was designed" for import*?
Even Tkinter (which just about everyone does "import *" on) also exports
sys, and everything from the "types" module, by accident too.
> If you're suggesting __exports__ is to patch over problems
> caused by "from foo import *", then I think you're barking up the
> wrong tree
> :-)
Indeed. But I'm suggesting that the problems that *can* arise from
"import*" illustrate the fundamental silliness of exporting things by
accident. It's come up much more often for me when I'm looking over
someone's shoulder, teaching them how to use dir() in an interactive shell
to answer their own damn questions <0.5 wink>. It's usually the case that
dir(M) shows them something that isn't documented, and over time I am *not*
pleased that "oh, I guess the 'string' in there is just crap" is how they
learn to view it.
I can live without __exports__; but I'd prefer not to, because I would
always use it if it were there.
if-i'd-both-use-it-and-heartily-recommend-it-it's-hard-to-
oppose-it-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