Re: PEP 420: Implicit Namespace Packages
"Eric V. Smith" <[email protected]>
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <[email protected]> |
On 4/19/2012 5:08 PM, Brett Cannon wrote: > In Terminology, can you put the terms when you define them in quotes, > e.g. 'The term "distribution" refers to ...'? > > "setuptools provides a similar function pkg_resources.declare_namespace" > should either have a "named" added in there or a comma. > > "As vendors might chose(sic) to". I've made these grammar changes. I'll update based on the rest of your comments tomorrow. Thanks! Eric. > You should mention that this will do away with the ImportWarning of > discovering a directory lacking an __init__.py file. > > As for the effects on path hooks, there are none. =) It's actually the > finders that they return which need to change. Either finders need to be > updated to return something other than None to signal they have a > directory which works for the name (maybe the string for what should go > into __path__?) or another method on finders which is called if > finder.find_module() returns None (like finder.find_namespace() which > returns the directory name or None). Then you need to update > importlib._bootstrap.PathFinder to handle one of the two approaches to > create the module and set it with some __loader__ (which really doesn't > need to do much more than construct a module with the proper attributes > since there is nothing to execute) like > importlib.machinery.NamespaceLoader(name, *paths). Using a specific > class in import already has precedence thanks to NullImporter. > > If you want performance then you go with the returning of a string by > finder.find_module() since the finder can keep track of finding a > directory w/o an __init__.py when it tries looking for a module. Import > can do a hasattr check on non-None return values to decide if it got > back a loader or a path for a namespace. If you don't like what the > return value to mean based on it being None or having a specific > attribute then you would want the new method at the (potential) cost of > another stat call. Or maybe someone can think of some other approach.