Moshe Zadka wrote: > > ... > 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". That's not the issue. It's not about keeping people out of your module. In fact I would propose that mod.__dict__ should be as loose as ever. It's a user interface issue. If we encourage people to learn about modules in interactive environments like the prompt using dir(), class browsers and IDEs then we need to create modules that are friendly for those users. I think that the current situation is pretty bad that way. what does CGIHTTPServer export BaseHTTPServer? And why is CGIHTTPServer.CGIHTTPServer a class but CGIHTTPServer.BaseHTTPServer is a module? We go to great lengths to make the syntax newbie friendly. I think that we should make similar efforts in a cleanly reflective class library. > 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 It's pretty clear that nobody does this now and nobody is going to start doing it in the near future. It's too invasive and it makes the code too ugly. Why obfuscate thousands of lines of code when a simple feature can mitigate that? >... > 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. __exports__ would merely be considered an implementation detail of the "default __getattr__". Custom __getattr__'s could decide whether to respect it or not. It doesn't complicate anything much. Paul Prescod
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