<div dir="ltr">I like the idea and I think it can be more-or-less safe. Just need more specification/clarification on things.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 2:34 AM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>This is an outgrowth of discussions on the .ref PEP, but it's also something I've been thinking about for over a year and starting toying with at the last PyCon. I have a patch that passes all but a couple unit tests and should pass though when I get a minute to take another pass at it. I'll probably end up adding a bunch more unit tests before I'm done as well. However, the functionality is mostly there.</div>
<div><br></div><div>BTW, I gotta say, Brett, I have a renewed appreciation for the long and hard effort you put into importlib. There are just so many odd corner cases that I never would have looked for if not for that library. And those unit tests do a great job of covering all of that. Thanks!</div>
</div></blockquote><div><br></div><div>Welcome! And yes, importlib didn't take multiple years out of laziness, but just how much work had to go in to cover corner cases along with pauses from frustration with the semantics. :P</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>-eric</div><div><br></div><div>-------------------------------------------------------------------------------</div><div><br></div><div>PEP: 4XX</div><div>Title: A ModuleSpec Type for the Import System</div>
<div>Version: $Revision$</div><div>Last-Modified: $Date$</div><div>Author: Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></div><div>BDFL-Delegate: ???</div>
<div>Discussions-To: <a href="mailto:import-sig@python.org" target="_blank">import-sig@python.org</a></div>
<div>Status: Draft</div><div>Type: Standards Track</div><div>Content-Type: text/x-rst</div><div>Created: 8-Aug-2013</div><div>Python-Version: 3.4</div><div>Post-History: 8-Aug-2013</div><div>Resolution:</div><div><br></div>
<div><br></div><div>Abstract</div><div>========</div><div><br></div><div>This PEP proposes to add a new class to ``importlib.machinery`` called</div><div>``ModuleSpec``. It will contain all the import-related information</div>
<div>about a module without needing to load the module first. Finders will</div><div>now return a module's spec rather than a loader. The import system will</div><div>use the spec to load the module.</div><div><br>
</div>
<div><br></div><div>Motivation</div><div>==========</div><div><br></div><div>The import system has evolved over the lifetime of Python. In late 2002</div><div>PEP 302 introduced standardized import hooks via ``finders`` and</div>
<div>``loaders`` and ``sys.meta_path``. The ``importlib`` module, introduced</div><div>with Python 3.1, now exposes a pure Python implementation of the APIs</div><div>described by PEP 302, as well as of the full import system. It is now</div>
<div>much easier to understand and extend the import system. While a benefit</div><div>to the Python community, this greater accessibilty also presents a</div><div>challenge.</div><div><br></div><div>As more developers come to understand and customize the import system,</div>
<div>any weaknesses in the finder and loader APIs will be more impactful. So</div><div>the sooner we can address any such weaknesses the import system, the</div><div>better...and there are a couple we can take care of with this proposal.</div>
<div><br></div><div>Firstly, any time the import system needs to save information about a</div><div>module we end up with more attributes on module objects that are</div><div>generally only meaningful to the import system and occoasionally to some</div>
<div>people. It would be nice to have a per-module namespace to put future</div><div>import-related information. Secondly, there's an API void between</div><div>finders and loaders that causes undue complexity when encountered.</div>
<div><br></div><div>Finders are strictly responsible for providing the loader which the</div><div>import system will use to load the module. The loader is then</div><div>responsible for doing some checks, creating the module object, setting</div>
<div>import-related attributes, "installing" the module to ``sys.modules``,</div><div>and loading the module, along with some cleanup. This all takes place</div><div>during the import system's call to ``Loader.load_module()``. Loaders</div>
<div>also provide some APIs for accessing data associated with a module.</div><div><br></div><div>Loaders are not required to provide any of the functionality of</div><div>``load_module()`` through other methods. Thus, though the import-</div>
<div>related information about a module is likely available without loading</div><div>the module, it is not otherwise exposed.</div><div><br></div><div>Furthermore, the requirements assocated with ``load_module()`` are</div>
<div>common to all loaders and mostly are implemented in exactly the same</div><div>way. This means every loader has to duplicate the same boilerplate</div><div>code. ``importlib.util`` provides some tools that help with this, but</div>
<div>it would be more helpful if the import system simply took charge of</div><div>these responsibilities. The trouble is that this would limit the degree</div><div>of customization that ``load_module()`` facilitates. This is a gap</div>
<div>between finders and loaders which this proposal aims to fill.</div><div><br></div><div>Finally, when the import system calls a finder's ``find_module()``, the</div><div>finder makes use of a variety of information about the module that is</div>
<div>useful outside the context of the method. Currently the options are</div><div>limited for persisting that per-module information past the method call,</div><div>since it only returns the loader. Either store it in a module-to-info</div>
<div>mapping somewhere like on the finder itself, or store it on the loader.</div></div></blockquote><div><br></div><div>The two previous sentences are hard to read; I think you were after something like,</div><div>"Popular options for this limitation are to store the information is in a module-to-info</div>
<div>mapping somewhere on the finder itself, or store it on the loader.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Unfortunately, loaders are not required to be module-specific. On top</div><div>of that, some of the useful information finders could provide is</div>
<div>common to all finders, so ideally the import system could take care of</div><div>that. This is the same gap as before between finders and loaders.</div><div><br></div><div>As an example of complexity attributable to this flaw, the</div>
<div>implementation of namespace packages in Python 3.3 (see PEP 420) added</div><div>``FileFinder.find_loader()`` because there was no good way for</div><div>``find_module()`` to provide the namespace path.</div><div><br>
</div><div>The answer to this gap is a ``ModuleSpec`` object that contains the</div><div>per-module information and takes care of the boilerplate functionality</div><div>of loading the module.</div><div><br></div><div>(The idea grew feet during discussions related to another PEP.[1])</div>
</div></blockquote><div><br></div><div>"(This PEP grew out of discussions related to another PEP [1])"</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div><br></div><div>Specification</div><div>=============</div><div><br></div><div>ModuleSpec</div><div>----------</div><div><br></div><div>A new class which defines the import-related values to use when loading</div>
<div>the module. It closely corresponds to the import-related attributes of</div><div>module objects. ``ModuleSpec`` objects may also be used by finders and</div><div>loaders and other import-related APIs to hold extra import-related</div>
<div>information about the module. This greatly reduces the need to add any</div><div>new import-related attributes to module objects.</div><div><br></div><div>Attributes:</div><div><br></div><div>* ``name`` - the module's name (compare to ``__name__``).</div>
<div>* ``loader`` - the loader to use during loading and for module data</div><div> (compare to ``__loader__``).</div><div>* ``package`` - the name of the module's parent (compare to</div><div> ``__package__``).</div>
<div>* ``is_package`` - whether or not the module is a package.</div></div></blockquote><div><br></div><div>I think is_package() is redundant in the face of 'name'/'package' or 'path' as you can introspect the same information. I honestly have always found it a weakness of InspectLoader.is_package() that it didn't return the value for __path__.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>* ``origin`` - the location from which the module originates.</div>
</div></blockquote><div><br></div><div>Don't quite follow what this is meant to represent? Like the path to the zipfile if loaded that way, otherwise it's the file path?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>* ``filename`` - like origin, but limited to a path-based location</div><div>
(compare to ``__file__``).</div><div>* ``cached`` - the location where the compiled module should be stored</div><div> (compare to ``__cached__``).</div><div>* ``path`` - the list of path entries in which to search for submodules</div>
<div> or ``None``. (compare to ``__path__``). It should be in sync with</div><div> ``is_package``.</div></div></blockquote><div><br></div><div>Why is 'path' the only attribute with a default value? Should probably say everything has a default value of None if not set/known.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Those are also the parameters to ``ModuleSpec.__init__()``, in that</div>
<div>order.</div></div></blockquote><div><br></div><div>I would consider arguing all arguments should be keyword-only past 'name' since there is no way most people will remember that order correctly.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> The last three are optional.</div></div>
</blockquote><div><br></div><div>(filename, cached, and path).</div><div><br></div><div>And that definitely makes is_package redundant if that's true.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div> When passed the values are taken</div>
<div>as-is. The ``from_loader()`` method offers calculated values.</div></div></blockquote><div><br></div><div>"(see below)."</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>Methods:</div><div><br></div><div>* ``from_loader(cls, ...)`` - returns a new ``ModuleSpec`` derived from the</div><div> arguments. The parameters are the same as with ``__init__``, except</div>
<div> ``package`` is excluded and only ``name`` and ``loader`` are required.</div></div></blockquote><div><br></div><div>Why the switch in requirements compared to __init__()?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>* ``module_repr()`` - returns a repr for the module.</div><div>* ``init_module_attrs(module)`` - sets the module's import-related</div>
<div> attributes.</div></div></blockquote><div><br></div><div>Specify what those attributes are and how they are set.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>* ``load(module=None, *, is_reload=False)`` - calls the loader's</div><div> ``exec_module()``, falling back to ``load_module()`` if necessary.</div><div> This method performs the former responsibilities of loaders for</div>
<div> managing modules before actually loading and for cleaning up. The</div><div> reload case is facilitated by the ``module`` and ``is_reload``</div><div> parameters.</div></div></blockquote><div><br></div><div>If a module is provided and there is already a matching key in sys.modules, what happens? What if is_reload is True but there is no module provided or in sys.modules; KeyError, ValueError, ImportError? Do you follow having None in sys.modules and raise ImportError, or do you overwrite (same question if a module is explicitly provided)?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Values Derived by from_loader()</div>
<div>-------------------------------</div><div><br></div><div>As implied above, ``from_loader()`` makes a best effort at calculating</div><div>any of the values that are not passed in. It duplicates the behavior</div><div>
that was formerly provided the several ``importlib.util`` functions as</div><div>well as the ``init_module_attrs()`` method of several of ``importlib``'s</div><div>loaders. Just to be clear, here is a more detailed description of those</div>
<div>calculations:</div><div><br></div><div>``is_package`` is derived from ``path``, if passed. Otherwise the</div><div>loader's ``is_package()`` is tried. Finally, it defaults to False.</div></div></blockquote><div>
<br></div><div>It can also be calculated based on whether ``name`` == ``package``: ``True if path is not None else name == package``.</div><div>Always need to watch out for [] for path as that is valid and signals the module is a package.</div>
<div><br></div><div>This is where defining exactly what details need to be passed in and which ones are optional are going to be critical in determining what represents ambiguity/unknown details vs. what is flat-out known to be true/false.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>``filename`` is pulled from the loader's ``get_filename()``, if</div>
<div>possible.</div><div><br></div><div>``path`` is set to an empty list if ``is_package`` is true, and the</div><div>directory from ``filename`` is appended to it, if available.</div><div><br></div><div>``cached`` is derived from ``filename`` if it's available.</div>
</div></blockquote><div><br></div><div>Derived how?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>``origin`` is set to ``filename``.</div><div><br></div><div>``package`` is set to ``name`` if the module is a package and</div></div></blockquote><div><br></div><div>"... is a package, else to ..."</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>to ``name.rpartition('.')[0]`` otherwise. Consequently, a</div>
<div>top-level module will have ``package`` set to the empty string.</div><div><br></div><div>Backward Compatibility</div><div>----------------------</div><div><br></div><div>Since finder ``find_module()``</div></div></blockquote>
<div><br></div><div>``Finder.find_module()``</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div> methods would now return a module spec</div>
<div>instead of loader, specs must act like the loader that would have been</div><div>returned instead. This is relatively simple to solve since the loader</div><div>is available as an attribute of the spec.</div></div>
</blockquote><div><br></div><div>Are you going to define a __getattr__ to delegate to the loader? Or are you going to specifically define equivalent methods, e.g. get_filename() is obviously solvable by getting the attribute from the spec (as long as filename is a required value)?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br>
</div><div>However, ``ModuleSpec.is_package`` (an attribute) conflicts with</div><div>``InspectLoader.is_package()`` (a method). Working around this requires</div><div>a more complicated solution but is not a large obstacle.</div>
<div><br></div><div>Unfortunately, the ability to proxy does not extend to ``id()``</div><div>comparisons and ``isinstance()`` tests. In the case of the return value</div><div>of ``find_module()``, we accept that break in backward compatibility.</div>
</div></blockquote><div><br></div><div>Mention that ModuleSpec can be added to the proper ABCs in importlib.abc to help alleviate this issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Subclassing</div><div>-----------</div><div><br></div><div>.. XXX Allowed but discouraged?</div></div></blockquote><div><br></div><div>Why should it matter if they are subclassed?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>Module Objects</div><div>--------------</div><div><br></div><div>Module objects will now have a ``__spec__`` attribute to which the</div>
<div>module's spec will be bound. None of the other import-related module</div><div>attributes will be changed or deprecated, though some of them could be.</div><div>Any such deprecation can wait until Python 4.</div>
</div></blockquote><div><br></div><div>"... could be; any such ..."</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>``ModuleSpec`` objects will not be kept in sync with the corresponding</div><div>module object's import-related attributes. They may differ, though in</div><div>practice they will be the same.</div>
</div></blockquote><div><br></div><div>"Though they may differ, in practice they will typically be the same." </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Finders</div><div>-------</div><div><br></div><div>Finders will now return ModuleSpec objects when ``find_module()`` is</div><div>called rather than loaders. For backward compatility, ``Modulespec``</div>
<div>objects proxy the attributes of their ``loader`` attribute.</div><div><br></div><div>Adding another similar method to avoid backward-compatibility issues</div><div>is undersireable if avoidable. The import APIs have suffered enough.</div>
</div></blockquote><div><br></div><div>in lieu of the fact that find_loader() was just introduced in Python 3.3.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>The approach taken by this PEP should be sufficient.</div><div><br></div><div>The change to ``find_module()`` applies to both ``MetaPathFinder`` and</div><div>``PathEntryFinder``. ``PathEntryFinder.find_loader()`` will be</div>
<div>deprecated and, for backward compatibility, implicitly special-cased if</div><div>the method exists on a finder.</div><div><br></div><div>Loaders</div><div>-------</div><div><br></div><div>Loaders will have a new method, ``exec_module(module)``. Its only job</div>
<div>is to "exec" the module and consequently populate the module's</div><div>namespace. It is not responsible for creating or preparing the module</div><div>object, nor for any cleanup afterward. It has no return value.</div>
<div><br></div><div>The ``load_module()`` of loaders will still work and be an active part</div><div>of the loader API. It is still useful for cases where the default</div><div>module creation/prepartion/cleanup is not appropriate for the loader.</div>
</div></blockquote><div><br></div><div>But will it still be required? Obviously importlib.abc.Loader can grow a default load_module() defined around exec_module(), but it should be clear if we expect the method to always be manually defined or if it will eventually go away.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>A loader must have ``exec_module()`` or ``load_module()`` defined. If</div><div>both exist on the loader, ``exec_module()`` is used and</div><div>``load_module()`` is ignored.</div></div></blockquote>
<div><br></div><div>Ignored by whom? Should specify that the import system is the one doing the ignoring.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>
PEP 420 introduced the optional ``module_repr()`` loader method to limit</div><div>the amount of special-casing in the module type's ``__repr__()``. Since</div><div>this method is part of ``ModuleSpec``, it will be deprecated on loaders.</div>
<div>However, if it exists on a loader it will be used exclusively.</div><div><br></div><div>The loader ``init_module_attr()`` method, added for Python 3.4 will be</div><div>eliminated in favor of the same method on ``ModuleSpec``.</div>
</div></blockquote><div><br></div><div>"method, added prior to Python 3.4's release, will be removed ..."</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>However, ``InspectLoader.is_package()`` will not be deprecated even</div><div>though the same information is found on ``ModuleSpec``. ``ModuleSpec``</div><div>can use it to populate its own ``is_package`` if that information is</div>
<div>not otherwise available. Still, it will be made optional.</div><div><br></div><div>In addition to executing a module during loading, loaders will still be</div><div>directly responsible for providing APIs concerning module-related data.</div>
<div><br></div><div>Other Changes</div><div>-------------</div><div><br></div><div>* The various finders and loaders provided by ``importlib`` will be</div><div>updated to comply with this proposal.</div><div><br></div><div>
* The spec for the ``__main__`` module will reflect how the interpreter</div><div>was started. For instance, with ``-m`` the spec's name will be that of</div><div>the run module, while ``__main__.__name__`` will still be "__main__".</div>
<div><br></div><div>* We add ``importlib.find_module()`` to mirror</div><div>``importlib.find_loader()`` (which becomes deprecated).</div><div><br></div><div>* Deprecations in ``importlib.util``: ``set_package()``,</div>
<div>
``set_loader()``, and ``module_for_loader()``. ``module_to_load()``</div><div>(introduced in 3.4) can be removed.</div></div></blockquote><div><br></div><div>"(introduced prior to Python 3.4's release)"; remember, PEPs are timeless and will outlive 3.4 so specifying it never went public is important.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>* ``importlib.reload()`` is changed to use ``ModuleSpec.load()``.</div>
<div><br></div>
<div>* ``ModuleSpec.load()`` and ``importlib.reload()`` will now make use of</div><div>the per-module import lock, whereas ``Loader.load_module()`` did not. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>Reference Implementation</div><div>------------------------</div>
<div><br></div><div>A reference implementation is available at <TBD>.</div><div><br></div><div><br></div><div>References</div><div>==========</div><div><br></div><div>[1] <a href="http://mail.python.org/pipermail/import-sig/2013-August/000658.html" target="_blank">http://mail.python.org/pipermail/import-sig/2013-August/000658.html</a></div>
<div><br></div><div><br></div><div>Copyright</div><div>=========</div><div><br></div><div>This document has been placed in the public domain.</div><div><br></div><div> </div><div>..</div><div> Local Variables:</div><div>
mode: indented-text</div><div> indent-tabs-mode: nil</div><div> sentence-end-double-space: t</div><div> fill-column: 70</div><div> coding: utf-8</div><div> End:</div><div><br></div></div>
<br>_______________________________________________<br>
Import-SIG mailing list<br>
<a href="mailto:Import-SIG@python.org" target="_blank">Import-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/import-sig" target="_blank">http://mail.python.org/mailman/listinfo/import-sig</a><br>
<br></blockquote></div><br></div></div>