[Tim Peters] > 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. [Greg Stein] > Simple question: so what? > > "Oh, no! My module exposes mod.sys! Oh, woe is me!" *snort* Let me "me to" here: Put another way, what Greg said is just a rephrase of "don't use from foo import * unless foo's docos say it's OK". Add to that the simple access control of a leading underscore, and I don't see any place which needs it. Something better to do would be to use import foo as _foo In some standard library modules, and minimize using from foo import bar in them. Since everyone know that leading underscore means "implementation detail - ignore at your convenience, use at yor peril", this would keep the "we're all adults" philosophy of Python, with all the advantages *I* see in __exports__. One more point against __exports__, which I hoped I would not have to make (but when I'm up against the timbot *and* Guido, I need to pull out the heavy artillery): it would *totally* stop any hope in the future of module level __getattr__ (or at least complicate the semantics). I think Alex M. is thinking of a PEP, but he's taking his time, since no PEPs can be considered until 2.1 is out. -- Moshe Zadka <sig@zadka.site.co.il> This is a signature anti-virus. Please stop the spread of signature viruses!
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