This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pje
Recipients Arfrever, barry, brett.cannon, eric.smith, eric.snow, georg.brandl, ncoghlan, pje, python-dev
Date 2012-08-02.23:49:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1343951400.49.0.898410564614.issue15502@psf.upfronthosting.co.za>
In-reply-to
Content
Per Nick's request that I redirect this here instead of #15295...  (w/already-fixed things deleted):

Hope I'm not too late to the bikeshed painting party; just wanted to chip in with the suggestion of "self-contained package" for non-namespace packages.  (i.e., a self-contained package is one that cannot be split across different sys.path entries due to its use of an __init__ module).

Also, technically, namespace portions do not only contribute subpackages; they can contribute modules as well.  (The trunk doc says they contribute subpackages ATM.)

Another point of possible confusion: meta finders and path finders are both described as "hooks", but this terminology seems in conflict with the use of "hook" as describing a callable on path_hooks.  Perhaps we could drop the term "hook" from this section, and retitle it "Import System Extensions" and say you can extend the system by writing meta finders and path entry finders.  This would let the term "hook" be the exclusive property of path_hooks, which is how you extend the import system to use your custom finders.

With respect to the current discussion about "importer", "handler", "finder", etc., I'd like to propose a slight tweak that I think can clear up the remaining confusing points:

1. Replace "meta path finder" with "import handler"
2. Replace "path finder" with "sys.path import handler"

Rationale:

Despite the similarity in interface between the two types of finders, they perform different sorts of functions.  A object in sys.meta_path can (and MUST) implement a broad module-finding policy, whereas a path entry finder is much more limited in scope - it only gets to override later path entry finders, and can't, for example, decide to use some other sort of __path__ attribute.  

(I'm not married to the term "handler" here, either - I just think "importer" is too generic, "finder" conflates with the more-commonly used kind of finder.  "Policy" could be another possibility.  Both imply a broader scope of responsibility than "finder", and don't impinge on the special meaning of "importer".)

With a bigger distinction drawn between these two types of finders, we can say that you...

"""Extend the import system by adding "import handlers" to sys.meta_path, and that one of the default handlers is the "sys.path import handler", which processes imports using sys.path and module __path__ attributes.

The sys.path import handler can of course in turn be extended by adding "path hooks" to sys.path_hooks, which are then used to create "module finder" objects for the path entry strings found in sys.path and module __path__ attributes.  A path hook must return a finder object, which implements similar methods to those of an import handler, but with some important differences.
"""

Of course, if you make that "sys.path import policy" instead of "sys.path import handler", it still works.

Thoughts?
History
Date User Action Args
2012-08-02 23:50:00pjesetrecipients: + pje, barry, brett.cannon, georg.brandl, ncoghlan, eric.smith, Arfrever, python-dev, eric.snow
2012-08-02 23:50:00pjesetmessageid: <1343951400.49.0.898410564614.issue15502@psf.upfronthosting.co.za>
2012-08-02 23:49:59pjelinkissue15502 messages
2012-08-02 23:49:58pjecreate