Movatterモバイル変換
[0]ホーム
[Import-SIG] PEP 420 issue: extend_path
Nick Coghlanncoghlan at gmail.com
Tue May 8 14:36:43 CEST 2012
On Tue, May 8, 2012 at 8:40 PM, Eric V. Smith <eric at trueblade.com> wrote:> In this case (supporting the now-legacy find_module API), you need to> make sure that find_loader returns None. So what you'd really want to do> is not define dir_found, and later in find_loader, where you've found an> __init__-less directory, say:>> if dir_found is None:> msg = "Not importing directory {}: missing __init__"> _warnings.warn(msg.format(dirpath), ImportWarning)> return None> dir_found(dirpath)> return NoneNo, the idea is to make the two activities (identifying packageportions and deciding whether or not to continue scanning sys.path)*independent*.I think "dir_found" is actually the wrong name for the proposedcallback. I would instead call it "portion_found". Also, since this isan API for third parties to implement, I think the default behaviourif no callback is specified should be to silently ignore discoveredportions - it would be up to FileFinder.find_module to pass in thecallback with the current ImportWarning behaviour.Suppose I want to implement a loader where the main path entry isactually just a reference to a separately configured path definition(e.g. to an application configuration file with an extra set of pathsto check for Python modules). With a callback API, I can implementthat directly, since I would be able to just pass the received"portion_found" callback down while scanning the subpath with theusual sys.path_hooks entries. It doesn't matter if that callback iscalled zero, one or many times - it will still do the right thing.Even if the subscan finds several portions before discovering aloader, it will *still* do the right thing - the fact we end upreturning return a loader instead of None would override the fact thatwe previously called "portion_found".With the current implementation, there's no option to return*multiple* path segments - loaders are restricted to returning at mostone portion to add to the namespace package.I think Antoine's right - having to introspect the return type fromthe method call is a major code smell, and I think it's a sign we'reasking one return value to serve too many different purposes.> Sure, the isinstance call is slightly ugly, but I don't see any downside> outside of aesthetics.How does a loader request that *multiple* entries be added to thenamespace package path? With the callback API, it can just invokes thecallback multiple times. Introspection on the return type wouldinstead need another special case.Regards,Nick.-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIGmailing list
[8]ページ先頭