Ka-Ping Yee wrote: > > On Wed, 10 Jan 2001, Guido van Rossum wrote: > > Yes -- I came up with the same thought. > > > > So here's a plan: somebody please submit a patch that does only one > > thing: from...import * looks for __all__ and if it exists, imports > > exactly those names. No changes to dir(), or anything. > > Please don't use __all__. At the moment, __all__ is the only way > to easily tell whether a particular module object really represents > a package, and the only way to get the list of submodule names. But __all__ has to be user-defined, so I don't buy that argument. Note that the only true way to recognize a package is by looking for an attribute "__path__" since Python adds this for packages only. > If __all__ is overloaded to also represent exportable symbols in > modules, these two pieces of information will be impossible (or > require much ugly hackery) to obtain. Again, __all__ is not automatically generated, so trusting it doesn't get you very far. To be able to find subpackages you will always have to apply some hackery (based on __path__) in order to be sure. It would be better to add a helper function to packages to query this kind of information -- the package usually knows best where to look and what to look for. Note that __all__ was explicitly invented to be used by from package import * so I think it is the right choice here. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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